Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9913 Independent
Category: Informational D. Cavalcanti
ISSN: 2070-1721 Intel
X. Vilajosana
Universitat Oberta de Catalunya
C. Schmitt
Research Institute CODE, UniBw M
J. Farkas
Ericsson
April 2026
This document surveys the short- and middle-range radio technologies over which providing Deterministic Networking (DetNet), and more specifically, Reliable and Available Wireless (RAW) service is suitable. It also presents the characteristics that RAW may leverage and explores the applicability of the technologies to carry deterministic flows, as of the time of publication. The studied technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS).
このドキュメントでは、Deterministic Networking (DetNet)、より具体的には Reliable and Availability Wireless (RAW) サービスの提供が適している短距離および中距離の無線技術について概説します。また、発行時点で、RAW が活用できる特性を示し、決定論的なフローを伝送するためのテクノロジーの適用可能性を検討します。研究対象となるテクノロジーは、Wi-Fi 6/7、タイムスロット チャネル ホッピング (TSCH)、3GPP 5G、および L バンド デジタル航空通信システム (LDACS) です。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9913.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9913 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Terminology
3. Towards Reliable and Available Wireless Networks
3.1. Scheduling for Reliability
3.2. Diversity for Availability
3.3. Benefits of Scheduling
4. IEEE 802.11 Wireless Local Area Networks (WLAN)
4.1. Provenance and Documents
4.2. 802.11ax High Efficiency (HE)
4.2.1. General Characteristics
4.2.2. Applicability to Deterministic Flows
4.3. 802.11be Extreme High Throughput (EHT)
4.3.1. General Characteristics
4.3.2. Applicability to Deterministic Flows
4.4. 802.11ad and 802.11ay (mmWave Operation)
4.4.1. General Characteristics
4.4.2. Applicability to Deterministic Flows
5. IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)
5.1. Provenance and Documents
5.2. General Characteristics
5.2.1. 6TiSCH Tracks
5.3. Applicability to Deterministic Flows
5.3.1. Centralized Path Computation
6. 5G
6.1. Provenance and Documents
6.2. General Characteristics
6.3. Deployment and Spectrum
6.4. Applicability to Deterministic Flows
6.4.1. System Architecture
6.4.2. Overview of the Radio Protocol Stack
6.4.3. Radio (PHY)
6.4.4. Scheduling and QoS (MAC)
6.4.5. Time-Sensitive Communications (TSC)
7. L-Band Digital Aeronautical Communications System (LDACS)
7.1. Provenance and Documents
7.2. General Characteristics
7.3. Deployment and Spectrum
7.4. Applicability to Deterministic Flows
7.4.1. System Architecture
7.4.2. Overview of the Radio Protocol Stack
7.4.3. Radio (PHY)
7.4.4. Scheduling, Frame Structure, and QoS (MAC)
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Deterministic Networking (DetNet) [RFC8557] provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques that might be used include (1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, (2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and (3) distributing data from DetNet flow packets over time and/or space (e.g., different frequencies or non-shared risk links) to ensure delivery of each packet in spite of the unavailability of a path.
Deterministic Networking (DetNet) [RFC8557] は、ネットワーク ドメイン内で極めて低いデータ損失率と制限された遅延で、リアルタイム アプリケーションに指定されたユニキャストまたはマルチキャスト データ フローを伝送する機能を提供します。使用される可能性のある技術には、(1) フローのパスに沿った中間ノードの一部またはすべてで個々の (または集約された) DetNet フローのデータ プレーン リソースを予約する、(2) ネットワーク トポロジによってすぐに変化しない DetNet フローの明示的なルートを提供する、(3) DetNet フロー パケットからのデータを時間および/または空間にわたって分散して (例: 異なる周波数や非共有リスク リンク)、ネットワークが利用できない場合でも各パケットの配信を確実にすることが含まれます。道。
DetNet operates at the IP layer and typically delivers service over wired lower-layer technologies such as Time-Sensitive Networking (TSN) as defined by IEEE 802.1 and IEEE 802.3.
DetNet は IP 層で動作し、通常、IEEE 802.1 および IEEE 802.3 で定義されている Time-Sensitive Networking (TSN) などの有線下位層テクノロジーを介してサービスを提供します。
The Reliable and Available Wireless (RAW) architecture [RFC9912] extends the DetNet architecture [RFC8655] to adapt to the specific challenges of the wireless medium, in particular, intermittently lossy connectivity, by optimizing the use of diversity and multipathing. [RFC9912] defines the concepts of reliability and availability that are used in this document. In turn, this document presents wireless technologies with capabilities, such as time synchronization and scheduling of transmission, that would make RAW operations possible over such media. The technologies studied in this document were identified in the charter during the RAW Working Group (WG) formation and inherited by DetNet (when the WG picked up the work on RAW).
Reliable and Availability Wireless (RAW) アーキテクチャ [RFC9912] は、ダイバーシティとマルチパスの使用を最適化することで、無線媒体の特定の課題、特に断続的な損失のある接続に適応するために DetNet アーキテクチャ [RFC8655] を拡張します。[RFC9912] は、この文書で使用される信頼性と可用性の概念を定義しています。次に、この文書では、時刻同期や送信のスケジューリングなどの機能を備えたワイヤレス テクノロジを紹介し、このようなメディア上で RAW 操作を可能にします。この文書で検討されているテクノロジーは、RAW ワーキング グループ (WG) の形成中に憲章で特定され、(WG が RAW に関する作業を取り上げたときに) DetNet に継承されました。
Making wireless reliable and available is even more challenging than it is with wires, due to the numerous causes of radio transmission losses that add up to the congestion losses and the delays caused by overbooked shared resources.
無線通信の信頼性と可用性を確保することは、有線の場合よりもさらに困難です。これは、無線伝送損失の原因が数多くあり、それらが輻輳損失やオーバーブッキングされた共有リソースによって引き起こされる遅延につながるためです。
RAW, like DetNet, needs and leverages lower-layer capabilities such as time synchronization and traffic shapers. To balance the adverse effects of the radio transmission losses, RAW leverages additional lower-layer capabilities, some of which may be specific or at least more typically applied to wireless. Such lower-layer techniques include:
RAW は、DetNet と同様に、時刻同期やトラフィック シェーパーなどの下位層の機能を必要とし、これを活用します。無線伝送損失の悪影響のバランスを取るために、RAW は追加の下位層機能を利用します。その機能の一部は、無線に特有のものであるか、少なくともより一般的に無線に適用される可能性があります。このような下位層の技術には次のようなものがあります。
* per-hop retransmissions (also known as Automatic Repeat Request (ARQ)),
* ホップごとの再送信 (自動再送要求 (ARQ) とも呼ばれます)、
* variation of the Modulation and Coding Scheme (MCS),
* 変調および符号化方式 (MCS) のバリエーション、
* short-range broadcast,
* 短距離放送、
* Multi-User - Multiple Input Multiple Output (MU-MIMO),
* マルチユーザー - 複数入力複数出力 (MU-MIMO)、
* constructive interference, and
* 建設的な干渉、そして
* overhearing whereby multiple receivers are scheduled to receive the same transmission, which saves both energy on the sender and spectrum.
* 複数の受信者が同じ送信を受信するようにスケジュールされるオーバーヒアリングにより、送信側とスペクトルの両方のエネルギーが節約されます。
These capabilities may be offered by the lower layer and may be controlled by RAW, separately or in combination.
これらの機能は下位層によって提供され、RAW によって個別にまたは組み合わせて制御される場合があります。
RAW defines a network-layer control loop that optimizes the use of links with constrained spectrum and energy while maintaining the expected connectivity properties, typically reliability and latency. The control loop involves communication monitoring through Operations, Administration, and Maintenance (OAM); path control through a Path Computation Element (PCE) and a runtime distributed Path Selection Engine (PSE); and extended Packet Replication, Elimination, and Ordering Functions (PREOF).
RAW は、期待される接続特性 (通常は信頼性と遅延) を維持しながら、スペクトルとエネルギーが制限されたリンクの使用を最適化するネットワーク層の制御ループを定義します。制御ループには、運用、管理、保守 (OAM) による通信の監視が含まれます。パス計算要素 (PCE) とランタイム分散パス選択エンジン (PSE) によるパス制御。および拡張パケット レプリケーション、エリミネーション、および順序付け機能 (PREOF)。
This document surveys the short- and middle-range radio technologies over which providing a RAW service is suitable, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows. The studied technologies are Wi-Fi 6/7, Time-Slotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS). The purpose of this document is to support and enable work on the these (and possibly other similar compatible technologies) at the IETF, specifically in the DetNet Working Group working on RAW.
この文書では、RAW サービスの提供に適した短距離および中距離の無線技術を調査し、RAW が活用できる特性を示し、決定論的なフローを伝送するための技術の適用可能性を検討します。研究対象となるテクノロジーは、Wi-Fi 6/7、タイムスロット チャネル ホッピング (TSCH)、3GPP 5G、および L バンド デジタル航空通信システム (LDACS) です。この文書の目的は、IETF、特に RAW に取り組んでいる DetNet Working Group でのこれら (およびおそらく他の同様の互換テクノロジ) の作業をサポートし、可能にすることです。
This document surveys existing networking technology; it does not define protocol behaviors or operational practices. The IETF specifications referenced herein each provide their own security considerations, and lower-layer technologies provide their own security at Layer 2; a security study of the technologies is explicitly not in scope.
この文書では、既存のネットワーク テクノロジについて概説します。プロトコルの動作や運用方法を定義するものではありません。ここで参照される IETF 仕様はそれぞれ独自のセキュリティに関する考慮事項を提供し、下位層のテクノロジはレイヤ 2 で独自のセキュリティを提供します。テクノロジーのセキュリティ調査は明らかに範囲外です。
This document uses the terminology and acronyms defined in Section 2 of [RFC8655] and Section 3 of [RFC9912].
この文書では、[RFC8655] のセクション 2 および [RFC9912] のセクション 3 で定義されている用語と頭字語を使用します。
A packet network is reliable for critical (e.g., time-sensitive) packets when the undesirable statistical effects that affect the transmission of those packets (e.g., delay or loss) are eliminated.
パケット ネットワークは、重要な (時間に敏感な) パケットの送信に影響を与える望ましくない統計的影響 (遅延や損失など) が排除されている場合に信頼できます。
The reliability of a deterministic network [RFC8655] often relies on precisely applying a tight schedule that controls the use of time-shared resources such as CPUs and buffers, and maintains at all times the number of the critical packets within the available resources of the communication hardware (e.g., buffers) and the transmission medium (e.g., bandwidth, transmission slots). The schedule can also be used to shape the flows by controlling the time of transmission of the packets that compose the flow at every hop.
決定論的ネットワーク [RFC8655] の信頼性は、多くの場合、CPU やバッファなどの時分割リソースの使用を制御し、通信ハードウェア (バッファなど) や伝送媒体 (帯域幅、伝送スロットなど) の利用可能なリソース内で重要なパケットの数を常に維持するタイトなスケジュールを正確に適用することに依存します。スケジュールは、ホップごとにフローを構成するパケットの送信時間を制御することにより、フローを形成するために使用することもできます。
To achieve this, there must be a shared sense of time throughout the network. The sense of time is usually provided by the lower layer and is not in scope for RAW. As an example, the Precision Time Protocol (PTP), standardized as IEEE 1588 and IEC 61588, has mapping through profiles to Ethernet, industrial and SmartGrid protocols, and Wi-Fi with IEEE Std 802.1AS.
これを実現するには、ネットワーク全体で時間の感覚が共有されている必要があります。時間の感覚は通常、下位層によって提供され、RAW の範囲には含まれません。一例として、IEEE 1588 および IEC 61588 として標準化された Precision Time Protocol (PTP) には、プロファイルを通じてイーサネット、産業用および SmartGrid プロトコル、および IEEE Std 802.1AS による Wi-Fi へのマッピングがあります。
Equipment (e.g., node) failure can be the cause of multiple packets being lost in a row before the flows are rerouted or the system recovers. Examples of equipment failure include a broken switch, an access point rebooting, a broken wire or radio adapter, or a fixed obstacle to the transmission.
機器 (ノードなど) の障害は、フローが再ルーティングされるかシステムが回復する前に複数のパケットが連続して失われる原因となる可能性があります。機器の障害の例には、スイッチの破損、アクセス ポイントの再起動、ワイヤまたは無線アダプタの破損、伝送に対する固定された障害物などがあります。
Equipment failure is not acceptable for critical applications such as those related to safety. A typical process control loop will tolerate an occasional packet loss, but a loss of several packets in a row will cause an emergency stop. In an amusement ride (e.g., at Disneyland, Universal Studios, or MGM Studios parks), a continuous loss of packets for a few 100 ms may trigger an automatic interruption of the ride and cause the evacuation of the attraction floor to restart it.
安全関連などの重要な用途では、機器の故障は許容できません。一般的なプロセス制御ループは、時折のパケット損失を許容しますが、連続して複数のパケットが損失すると、緊急停止が発生します。遊園地の乗り物 (ディズニーランド、ユニバーサル スタジオ、または MGM スタジオのパークなど) では、数 100 ミリ秒の継続的なパケット損失により、乗り物が自動的に中断され、乗り物を再開するためにアトラクション フロアが避難する可能性があります。
Network availability is obtained by making the transmission resilient against hardware failures and radio transmission losses due to uncontrolled events such as co-channel interferers, multipath fading, or moving obstacles. The best results are typically achieved by pseudorandomly cumulating all forms of diversity -- in the spatial domain with replication and elimination, in the time domain with ARQ and diverse scheduled transmissions, and in the frequency domain with frequency hopping or channel hopping between frames.
ネットワークの可用性は、ハードウェア障害や、同一チャネル干渉、マルチパス フェージング、移動障害物などの制御不能なイベントによる無線伝送損失に対する伝送の回復力を高めることによって得られます。通常、最良の結果は、空間領域では複製と削除、時間領域では ARQ とさまざまなスケジュールされた送信、周波数領域ではフレーム間の周波数ホッピングまたはチャネル ホッピングなど、あらゆる形式のダイバーシティを擬似ランダムに累積することによって達成されます。
Scheduling redundant transmissions of the critical packets on diverse paths improves the resiliency against breakages and statistical transmission loss, such as those due to cosmic particles on wires and interferences on wireless. While transmission losses are orders of magnitude more frequent on wireless, redundancy and diversity are needed in all cases for life- and mission-critical applications.
多様なパス上で重要なパケットの冗長伝送をスケジュールすることにより、有線上の宇宙粒子や無線上の干渉による破損や統計的伝送損失に対する回復力が向上します。無線では伝送損失が桁違いに多く発生しますが、ライフクリティカルなアプリケーションやミッションクリティカルなアプリケーションでは、あらゆる場合に冗長性と多様性が必要です。
When required, the worst-case time of delivery can be guaranteed as part of the end-to-end schedule, and the sense of time that must be shared throughout the network can be exposed to and leveraged by other applications.
必要に応じて、最悪の場合の配信時間をエンドツーエンドのスケジュールの一部として保証することができ、ネットワーク全体で共有する必要がある時間感覚を他のアプリケーションに公開して利用することができます。
In addition, scheduling provides specific value over the wireless medium:
さらに、スケジューリングは無線媒体上で特定の価値を提供します。
* Scheduling allows a time-sharing operation, where every transmission is assigned its own time/frequency resource. The sender and receiver are synchronized and scheduled to talk on a given frequency resource at a given time and for a given duration. This way, scheduling can avoid collisions between scheduled transmissions and enable a high ratio of critical traffic (think 60% or 70% of high-priority traffic with ultra low loss) compared to statistical priority-based schemes.
* スケジューリングにより、すべての送信に独自の時間/周波数リソースが割り当てられる、タイムシェアリング操作が可能になります。送信者と受信者は同期されており、指定された時刻に指定された期間、指定された周波数リソースで通話するようにスケジュールされています。このようにして、スケジューリングにより、スケジュールされた送信間の衝突を回避し、統計的優先度ベースのスキームと比較して、クリティカルなトラフィックの高い比率 (超低損失の高優先度トラフィックの 60% または 70% を考えてください) を可能にすることができます。
* Scheduling can be used as a technique for both time and frequency diversity (e.g., between transmission retries), allowing the next transmission to happen on a different frequency as programmed in both the sender and the receiver. This is useful to defeat co-channel interference from uncontrolled transmitters as well as multipath fading.
* スケジューリングは、時間と周波数の両方のダイバーシティ (送信の再試行間など) の技術として使用でき、送信側と受信側の両方でプログラムされたとおりに、次の送信を異なる周波数で行うことができます。これは、制御されていない送信機からの同一チャネル干渉やマルチパス フェージングを防ぐのに役立ちます。
* Transmissions can be also scheduled on multiple channels in parallel, which enables the use of the full available spectrum while avoiding the hidden terminal problem, e.g., when the next packet in a same flow interferes on a same channel with the previous one that progressed a few hops farther.
* 送信は複数のチャネルで並行してスケジュールすることもでき、これにより、隠れ端末の問題、たとえば、同じフロー内の次のパケットが同じチャネル上で数ホップ先に進んだ前のパケットと干渉する場合を回避しながら、利用可能なスペクトルをすべて使用できるようになります。
* Scheduling optimizes the bandwidth usage. Compared to classical collision avoidance techniques, there is no blank time related to Interframe Space (IFS) and exponential back-off in scheduled operations. A minimal clear channel assessment may be needed to comply with the local regulations such as ETSI 300-328, but that will not detect a collision when the senders are synchronized.
* スケジューリングにより、帯域幅の使用が最適化されます。従来の衝突回避技術と比較すると、スケジュールされた操作ではフレーム間スペース (IFS) や指数関数的バックオフに関連する空白時間がありません。ETSI 300-328 などの現地の規制に準拠するには、最小限のクリア チャネル評価が必要な場合がありますが、送信者が同期しているときに衝突は検出されません。
* Scheduling plays a critical role in saving energy. In the Internet of Things (IoT), energy is the foremost concern, and synchronizing the sender and listener enables always maintaining them in deep sleep when there is no scheduled transmission. This avoids idle listening and long preambles, and it enables long sleep periods between traffic and resynchronization, allowing battery-operated nodes to operate in a mesh topology for multiple years.
* スケジュール設定はエネルギーの節約において重要な役割を果たします。モノのインターネット (IoT) ではエネルギーが最も重要な問題であり、送信側と受信側を同期させることで、スケジュールされた送信がない場合は常にディープ スリープ状態に保つことができます。これにより、アイドル状態のリスニングと長いプリアンブルが回避され、トラフィックと再同期の間の長いスリープ期間が可能になり、バッテリー駆動のノードがメッシュ トポロジで数年間動作できるようになります。
In recent years, the evolution of the IEEE Std 802.11 standard has taken a new direction, emphasizing improved reliability and reduced latency in addition to minor improvements in speed, to enable new fields of application such as industrial IoT and Virtual Reality (VR).
近年、IEEE Std 802.11 規格の進化は、速度のわずかな向上に加えて、信頼性の向上と遅延の短縮を強調する新たな方向を向いており、産業用 IoT や仮想現実 (VR) などの新しいアプリケーション分野を可能にしています。
Leveraging IEEE Std 802.11, the Wi-Fi Alliance [WFA] delivered Wi-Fi 6, 7, and now 8 with more capabilities to schedule and deliver frames in due time at fast rates. Still, as with any radio technology, Wi-Fi is sensitive to frame loss, which can only be combated with the maximum use of diversity in space, time, channel, and even technology.
Wi-Fi Alliance [WFA] は、IEEE Std 802.11 を活用して、高速で適切なタイミングでフレームをスケジュールして配信する機能をさらに強化した Wi-Fi 6、7、そして現在の 8 を提供しました。それでも、他の無線技術と同様に、Wi-Fi はフレーム損失に敏感であり、これに対処するには、空間、時間、チャネル、さらにはテクノロジーの多様性を最大限に活用する必要があります。
In parallel, the Avnu Alliance [Avnu], which focuses on applications of TSN for real-time data, formed a workgroup to investigate TSN capabilities over wireless, leveraging both 3GPP and IEEE Std 802.11 standards.
並行して、リアルタイム データ用の TSN アプリケーションに焦点を当てている Avnu Alliance [Avnu] は、3GPP と IEEE Std 802.11 標準の両方を活用して、ワイヤレスでの TSN 機能を調査するためのワークグループを結成しました。
To achieve the latter, the reliability must be handled at an upper layer that can select Wi-Fi and other wired or wireless technologies for parallel transmissions. This is where RAW comes into play.
後者を実現するには、並列伝送用に Wi-Fi およびその他の有線または無線テクノロジーを選択できる上位層で信頼性を処理する必要があります。ここでRAWが活躍します。
This section surveys the IEEE 802.11 features that are most relevant to RAW, noting that there are a great many more in the specification, some of which may also possibly be of interest for a RAW solution. For instance, frame fragmentation reduces the impact of a very transient transmission loss, both on latency and energy consumption.
このセクションでは、RAW に最も関連する IEEE 802.11 の機能を概説し、仕様にはさらに多くの機能があり、そのうちのいくつかは RAW ソリューションにとって興味深い可能性があることに注意します。たとえば、フレームの断片化により、遅延とエネルギー消費の両方に対する非常に一時的な伝送損失の影響が軽減されます。
The IEEE 802 LAN/MAN Standards Committee (SC) develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks using an open and accredited process, and it advocates them on a global basis. The most widely used standards are for Ethernet, Bridging and Virtual Bridged LAN, Wireless LAN, Wireless Personal Area Network (PAN), Wireless MAN, Wireless Coexistence, Media Independent Handover Services, and Wireless Radio Access Network (RAN). An individual working group provides the focus for each area.
IEEE 802 LAN/MAN 標準委員会 (SC) は、オープンで認定されたプロセスを使用して、ローカル、メトロポリタン、およびその他のエリア ネットワークのネットワーキング標準と推奨慣行を開発および維持し、それらを世界規模で提唱しています。最も広く使用されている標準は、イーサネット、ブリッジングおよび仮想ブリッジ LAN、無線 LAN、無線パーソナル エリア ネットワーク (PAN)、無線 MAN、無線共存、メディア独立ハンドオーバー サービス、および無線無線アクセス ネットワーク (RAN) 用です。個別の作業グループが各分野に焦点を当てます。
The IEEE 802.11 Wireless LAN (WLAN) standards define the underlying Medium Access Control (MAC) and Physical (PHY) layers for the Wi-Fi technology. While previous 802.11 generations, such as 802.11n and 802.11ac, focused mainly on improving peak throughput, more recent generations are also considering other performance vectors, such as efficiency enhancements for dense environments in IEEE Std 802.11ax [IEEE802.11ax] (approved in 2021) and throughput, latency, and reliability enhancements in IEEE Std 802.11be [IEEE802.11be] (approved in 2024).
IEEE 802.11 無線 LAN (WLAN) 標準は、Wi-Fi テクノロジーの基礎となる媒体アクセス制御 (MAC) 層と物理 (PHY) 層を定義します。802.11n や 802.11ac などの以前の 802.11 世代は主にピーク スループットの向上に焦点を当てていましたが、より最近の世代では、IEEE Std 802.11ax [IEEE802.11ax] (2021 年承認) の高密度環境の効率強化や IEEE Std 802.11be のスループット、遅延、信頼性の強化など、他のパフォーマンス ベクトルも考慮されています。[IEEE802.11be]（2024年承認）。
IEEE Std 802.11-2012 includes support for TSN time synchronization based on IEEE 802.1AS over the 802.11 Timing Measurement protocol. IEEE Std 802.11-2016 additionally includes an extension to the 802.1AS operation over 802.11 for Fine Timing Measurement (FTM), as well as the Stream Reservation Protocol (IEEE 802.1Qat). 802.11 WLANs can also be part of 802.1Q bridged networks with enhancements enabled by the 802.11ak amendment retrofitted in IEEE Std 802.11-2020. Traffic classification based on 802.1Q VLAN tags is also supported in 802.11. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11. The IEEE Std 802.11ax-2021 (which has been incorporated into IEEE Std 802.11-2024) defines additional scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower-bounded latency. IEEE 802.11be introduces features to enhance the support for 802.1 TSN capabilities, especially those related to worst-case latency, reliability, and availability.
IEEE Std 802.11-2012 には、802.11 タイミング測定プロトコルを介した IEEE 802.1AS に基づく TSN 時刻同期のサポートが含まれています。IEEE Std 802.11-2016 には、ファイン タイミング測定 (FTM) およびストリーム予約プロトコル (IEEE 802.1Qat) のための 802.11 上での 802.1AS 動作の拡張機能も含まれています。802.11 WLAN は、IEEE Std 802.11-2020 に組み込まれた 802.11ak 修正によって有効になった拡張機能を備えた 802.1Q ブリッジ ネットワークの一部にすることもできます。802.1Q VLAN タグに基づくトラフィック分類も 802.11 でサポートされています。メディアに依存しない 802.1Qbv や 802.1CB などの他の 802.1 TSN 機能は、すでに 802.11 上で動作できます。IEEE Std 802.11ax-2021 (IEEE Std 802.11-2024 に組み込まれています) は、802.11 MAC の適時性パフォーマンスを強化し、より低い限界遅延を達成できる追加のスケジューリング機能を定義しています。IEEE 802.11be では、802.1 TSN 機能、特に最悪の場合の遅延、信頼性、可用性に関連する機能のサポートを強化する機能が導入されています。
The IEEE 802.11 Working Group has been working in collaboration with the IEEE 802.1 Working Group for several years, extending some 802.1 features over 802.11. As with any wireless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and trade-offs between latency and reliability guarantees must be considered as well as managed deployment requirements. An overview of 802.1 TSN capabilities and challenges for their extensions to 802.11 are discussed in [Cavalcanti_2019].
IEEE 802.11 ワーキング グループは、数年間にわたって IEEE 802.1 ワーキング グループと協力して、802.1 の一部の機能を 802.11 上に拡張してきました。他のワイヤレス メディアと同様に、802.11 は TSN グレードの QoS に新しい制約と制限を課し、管理された展開要件だけでなく遅延と信頼性の保証の間のトレードオフも考慮する必要があります。802.1 TSN 機能の概要と 802.11 への拡張の課題については、[Cavalcanti_2019] で説明されています。
The Wi-Fi Alliance is the worldwide network of companies that drives global Wi-Fi adoption and evolution through thought leadership, spectrum advocacy, and industry-wide collaboration. The WFA work helps ensure that Wi-Fi devices and networks provide users the interoperability, security, and reliability they have come to expect.
Wi-Fi Alliance は、ソート リーダーシップ、スペクトル擁護、業界全体のコラボレーションを通じて世界的な Wi-Fi の導入と進化を推進する世界的な企業ネットワークです。WFA の取り組みは、Wi-Fi デバイスとネットワークがユーザーに期待する相互運用性、セキュリティ、信頼性を確実に提供するのに役立ちます。
The Avnu Alliance is also a global industry forum developing interoperability testing for TSN-capable devices across multiple media including Ethernet, Wi-Fi, and 5G.
Avnu Alliance は、イーサネット、Wi-Fi、5G などの複数のメディアにわたる TSN 対応デバイスの相互運用性テストを開発する世界的な業界フォーラムでもあります。
The following IEEE Std 802.11 specifications/certifications [IEEE802.11] are relevant in the context of reliable and available wireless services and support for TSN capabilities:
以下の IEEE Std 802.11 仕様/認証 [IEEE802.11] は、信頼性が高く利用可能なワイヤレス サービスと TSN 機能のサポートに関連しています。
* Time synchronization: IEEE Std 802.11-2016 with IEEE Std 802.1AS; WFA TimeSync Certification
* 時刻同期: IEEE Std 802.11-2016 と IEEE Std 802.1AS。WFA TimeSync 認定
* Congestion control: IEEE Std 802.11-2016 Admission Control; WFA Admission Control
* 輻輳制御: IEEE Std 802.11-2016 アドミッション コントロール。WFA アドミッション コントロール
* Security: WFA Wi-Fi Protected Access, WPA2, and WPA3
* セキュリティ: WFA Wi-Fi Protected Access、WPA2、および WPA3
* Interoperating with IEEE 802.1Q bridges: IEEE Std 802.11-2020 incorporating 802.11ak
* IEEE 802.1Q ブリッジとの相互運用: 802.11ak を組み込んだ IEEE Std 802.11-2020
* Stream Reservation Protocol (part of [IEEE802.1Qat]): IEEE802.11-2016
* ストリーム予約プロトコル ([IEEE802.1Qat] の一部): IEEE802.11-2016
* Scheduled channel access: IEEE 802.11ad enhancements for very high throughput in the 60 GHz band [IEEE802.11ad]
* スケジュールされたチャネル アクセス: 60 GHz 帯域での非常に高いスループットを実現する IEEE 802.11ad の機能強化 [IEEE802.11ad]
* 802.11 Real-Time Applications: Topic Interest Group (TIG) ReportDoc [IEEE_doc_11-18-2009-06]
* 802.11 リアルタイム アプリケーション: トピック インタレスト グループ (TIG) ReportDoc [IEEE_doc_11-18-2009-06]
In addition, major amendments being developed by the IEEE 802.11 Working Group include capabilities that can be used as the basis for providing more reliable and predictable wireless connectivity and support time-sensitive applications:
さらに、IEEE 802.11 ワーキング グループによって開発中の主要な修正には、より信頼性が高く予測可能なワイヤレス接続を提供し、時間に敏感なアプリケーションをサポートするための基礎として使用できる機能が含まれています。
* [IEEE802.11ax]: Enhancements for High Efficiency (HE)
* [IEEE802.11ax]: 高効率のための拡張機能 (HE)
* [IEEE802.11be]: Extreme High Throughput (EHT)
* [IEEE802.11be]: 超高スループット (EHT)
* [IEEE802.11ay]: Enhanced throughput for operation in license-exempt bands above 45 GHz
* [IEEE802.11ay]: 45 GHz を超えるライセンス免除帯域での動作のための強化されたスループット
The main 802.11ax, 802.11be, 802.11ad, and 802.11ay capabilities and their relevance to RAW are discussed in the remainder of this section. As P802.11bn is still in early stages of development, its capabilities are not included in this document.
802.11ax、802.11be、802.11ad、および 802.11ay の主な機能と、RAW との関連性については、このセクションの残りの部分で説明します。P802.110 億はまだ開発の初期段階にあるため、その機能はこのドキュメントには含まれていません。
The next generation Wi-Fi (Wi-Fi 6) is based on the IEEE802.11ax amendment [IEEE802.11ax], which includes specific capabilities to increase efficiency and control and to reduce latency. Some of these features include higher-order 1024-QAM modulation, support for uplink (UL) Multi-User - Multiple Input Multiple Output (MU-MIMO), Orthogonal Frequency-Division Multiple Access (OFDMA), trigger-based access, and Target Wake Time (TWT) for enhanced power savings. The OFDMA mode and trigger-based access enable the Access Point (AP), after reserving the channel using the clear channel assessment procedure for a given duration, to schedule multi-user transmissions, which is a key capability required to increase latency predictability and reliability for time-sensitive flows. 802.11ax can operate in up to 160 MHz channels, and it includes support for operation in the new 6 GHz band, which has been open to unlicensed use by the Federal Communications Commission (FCC) and other regulatory agencies worldwide.
次世代 Wi-Fi (Wi-Fi 6) は、IEEE802.11ax 修正 [IEEE802.11ax] に基づいており、効率と制御を向上させ、遅延を短縮するための特定の機能が含まれています。これらの機能の一部には、高次 1024-QAM 変調、アップリンク (UL) マルチユーザー - 多入力多出力 (MU-MIMO)、直交周波数分割多元接続 (OFDMA)、トリガーベースのアクセス、省電力強化のためのターゲット ウェイク タイム (TWT) のサポートが含まれます。OFDMA モードとトリガーベースのアクセスにより、アクセス ポイント (AP) は、クリア チャネル評価手順を使用して一定期間チャネルを予約した後、マルチユーザー送信をスケジュールできます。これは、時間に敏感なフローの遅延の予測可能性と信頼性を高めるために必要な重要な機能です。802.11ax は最大 160 MHz チャネルで動作でき、新しい 6 GHz 帯域での動作のサポートが含まれています。この帯域は、連邦通信委員会 (FCC) および世界中のその他の規制機関によって無許可で使用されています。
802.11ax introduced an OFDMA mode in which multiple users can be scheduled across the frequency domain. In this mode, the Access Point (AP) can initiate multi-user UL transmissions in the same PHY Protocol Data Unit (PPDU) by sending a trigger frame. This centralized scheduling capability gives the AP much more control of the channel in its Basic Service Set (BSS), and it can remove contention between associated stations for UL transmissions, therefore reducing the randomness caused by access based on Carrier Sense Multiple Access (CSMA) between stations within the same BSS. The AP can also transmit simultaneously to multiple users in the downlink (DL) direction by using a DL MU OFDMA PPDU. In order to initiate a contention-free Transmission Opportunity (TXOP) using the OFDMA mode, the AP still follows the typical listen-before-talk procedure to acquire the medium, which ensures interoperability and compliance with unlicensed band access rules. However, 802.11ax also includes a Multi-User Enhanced Distributed Channel Access (MU-EDCA) capability, which allows the AP to get higher channel access priority than other devices in its BSS.
802.11ax では、周波数領域全体で複数のユーザーをスケジュールできる OFDMA モードが導入されました。このモードでは、アクセス ポイント (AP) はトリガー フレームを送信することで、同じ PHY プロトコル データ ユニット (PPDU) でマルチユーザー UL 送信を開始できます。この集中スケジューリング機能により、AP は Basic Service Set (BSS) 内のチャネルをより詳細に制御できるようになり、UL 送信の関連ステーション間の競合を取り除くことができるため、同じ BSS 内のステーション間の Carrier Sense Multiple Access (CSMA) に基づくアクセスによって引き起こされるランダム性が軽減されます。AP は、DL MU OFDMA PPDU を使用して、ダウンリンク (DL) 方向で複数のユーザーに同時に送信することもできます。OFDMA モードを使用して競合のない送信機会 (TXOP) を開始するために、AP は通常のリッスン ビフォア トーク手順に従ってメディアを取得します。これにより、相互運用性とアンライセンス バンド アクセス ルールへの準拠が保証されます。ただし、802.11ax にはマルチユーザー拡張分散チャネル アクセス (MU-EDCA) 機能も含まれており、これにより AP は BSS 内の他のデバイスよりも高いチャネル アクセス優先度を取得できます。
802.11ax relies on the notion of an OFDMA Resource Unit (RU) to allocate frequency chunks to different stations over time. RUs provide a way to allow multiple stations to transmit simultaneously, starting and ending at the same time. The way this is achieved is via padding, where extra bits are transmitted with the same power level. The current RU allocation algorithms provide a way to achieve traffic isolation per station. While this does not support time-aware scheduling per se, it is a key aspect to assist reliability, as it provides traffic isolation in a shared medium.
802.11ax は、OFDMA リソース ユニット (RU) の概念に依存して、時間の経過とともに周波数チャンクをさまざまなステーションに割り当てます。RU は、複数のステーションが同時に送信を開始し、同時に終了できるようにする方法を提供します。これを実現する方法はパディングを介して行われ、余分なビットが同じ電力レベルで送信されます。現在の RU 割り当てアルゴリズムは、ステーションごとにトラフィックを分離する方法を提供します。これは時間認識スケジューリング自体をサポートしませんが、共有メディアでトラフィックを分離するため、信頼性を高めるための重要な側面です。
The 802.11ax PHY can operate with a 0.8, 1.6, or 3.2 microsecond Guard Interval (GI). The larger GI options provide better protection against multipath, which is expected to be a challenge in industrial environments. The possibility of operating with smaller RUs (e.g., 2 MHz) enabled by OFDMA also helps reduce noise power and improve Signal-to-Noise Ratio (SNR), leading to better Packet Error Rate (PER) performance.
802.11ax PHY は、0.8、1.6、または 3.2 マイクロ秒のガード インターバル (GI) で動作できます。GI オプションが大きいほど、産業環境では課題となることが予想されるマルチパスに対する保護が強化されます。OFDMA によって有効になる、より小さい RU (2 MHz など) で動作できる可能性も、ノイズ電力を削減し、信号対雑音比 (SNR) を向上させるのに役立ち、パケット誤り率 (PER) のパフォーマンスの向上につながります。
802.11ax supports beamforming as in 802.11ac but introduces UL MU-MIMO, which helps improve reliability. The UL MU-MIMO capability is also enabled by the trigger-based access operation in 802.11ax.
802.11ax は 802.11ac と同様にビームフォーミングをサポートしますが、信頼性の向上に役立つ UL MU-MIMO を導入しています。UL MU-MIMO 機能は、802.11ax のトリガーベースのアクセス操作によっても有効になります。
The 802.11ax specification [IEEE802.11ax] includes support for operation in the 6 GHz band. Given the amount of new spectrum available, as well as the fact that no legacy 802.11 device (prior 802.11ax) will be able to operate in this band, 802.11ax operation in this new band can be even more efficient.
802.11ax 仕様 [IEEE802.11ax] には、6 GHz 帯域での動作のサポートが含まれています。利用可能な新しいスペクトルの量と、この帯域で動作できる従来の 802.11 デバイス (以前の 802.11ax) が存在しないという事実を考慮すると、この新しい帯域での 802.11ax 動作はさらに効率的になる可能性があります。
TSN capabilities, as defined by the IEEE 802.1 TSN standards, provide the underlying mechanism for supporting deterministic flows in a Local Area Network (LAN). The IEEE 802.11 Working Group has incorporated support for absolute time synchronization to extend the TSN 802.1AS protocol so that time-sensitive flows can experience precise time synchronization when operating over 802.11 links. As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement some TSN capabilities without the need for a gateway/translation protocol. Basic features required for operation in a 802.1Q LAN are already enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can already operate over the existing 802.11 MAC Service Access Point (SAP) [Sudhakaran2021]. Implementation and experimental results of TSN capabilities (802.1AS, 802.1Qbv, and 802.1CB) extended over standard Ethernet and Wi-Fi devices have also been described in [Fang_2021]. Nevertheless, the IEEE 802.11 MAC/PHY could be extended to improve the operation of IEEE 802.1 TSN features and achieve better performance metrics [Cavalcanti1287].
IEEE 802.1 TSN 標準で定義されている TSN 機能は、ローカル エリア ネットワーク (LAN) で決定論的なフローをサポートするための基礎となるメカニズムを提供します。IEEE 802.11 ワーキング グループは、TSN 802.1AS プロトコルを拡張する絶対時刻同期のサポートを組み込み、時間に敏感なフローが 802.11 リンク上で動作するときに正確な時刻同期を実現できるようにしました。IEEE 802.11 と IEEE 802.1 TSN は両方とも IEEE 802 アーキテクチャに基づいているため、802.11 デバイスはゲートウェイ/変換プロトコルを必要とせずに一部の TSN 機能を直接実装できます。802.1Q LAN での動作に必要な基本機能は、802.11 に対してすでに有効になっています。802.1Qbv などの一部の TSN 機能は、既存の 802.11 MAC サービス アクセス ポイント (SAP) 上ですでに動作できます [Sudhakaran2021]。標準イーサネットおよび Wi-Fi デバイス上に拡張された TSN 機能 (802.1AS、802.1Qbv、および 802.1CB) の実装と実験結果も [Fang_2021] に記載されています。それにもかかわらず、IEEE 802.11 MAC/PHY を拡張して、IEEE 802.1 TSN 機能の動作を改善し、より優れたパフォーマンス メトリックを達成することは可能です [Cavalcanti1287]。
TSN capabilities supported over 802.11 (which also extends to 802.11ax) include:
802.11 (802.11ax にも拡張) でサポートされる TSN 機能には次のものがあります。
1. 802.1AS-based time synchronization (other time synchronization techniques may also be used)
1. 802.1AS ベースの時刻同期 (他の時刻同期技術も使用される場合があります)
2. Interoperating with IEEE 802.1Q bridges
2. IEEE 802.1Q ブリッジとの相互運用
3. Time-sensitive traffic stream classification
3. 時間に依存するトラフィック ストリームの分類
The existing 802.11 TSN capabilities listed above, and the 802.11ax OFDMA and AP-controlled access within a BSS, provide a new set of tools to better serve time-sensitive flows. However, it is important to understand the trade-offs and constraints associated with such capabilities, as well as redundancy and diversity mechanisms that can be used to provide more predictable and reliable performance.
上記の既存の 802.11 TSN 機能、および 802.11ax OFDMA および BSS 内の AP 制御アクセスは、時間に敏感なフローをより適切に処理するための新しいツール セットを提供します。ただし、そのような機能に関連するトレードオフと制約、およびより予測可能で信頼性の高いパフォーマンスを提供するために使用できる冗長性と多様性のメカニズムを理解することが重要です。
Time-sensitive applications and TSN standards are expected to operate in a managed network (e.g., an industrial/enterprise network). This enables careful management and integration of the Wi-Fi operation with the overall TSN management framework, as defined in [IEEE802.1Qcc].
時間に敏感なアプリケーションと TSN 標準は、管理されたネットワーク (産業/エンタープライズ ネットワークなど) で動作することが期待されています。これにより、[IEEE802.1Qcc] で定義されているように、慎重な管理と Wi-Fi 動作の全体的な TSN 管理フレームワークとの統合が可能になります。
Some of the random-access latency and interference from legacy/ unmanaged devices can be reduced under a centralized management mode as defined in [IEEE802.1Qcc].
[IEEE802.1Qcc] で定義されている集中管理モードでは、ランダムアクセス遅延とレガシー/管理対象外デバイスからの干渉の一部を削減できます。
Existing traffic stream identification, configuration, and admission control procedures defined in the QoS mechanism in [IEEE802.11] can be reused. However, given the high degree of determinism required by many time-sensitive applications, additional capabilities to manage interference and legacy devices within tight time constraints need to be explored.
[IEEE802.11] の QoS メカニズムで定義されている既存のトラフィック ストリームの識別、設定、およびアドミッション制御手順を再利用できます。ただし、多くの時間に敏感なアプリケーションでは高度な決定性が必要とされるため、厳しい時間制約内で干渉やレガシー デバイスを管理するための追加機能を検討する必要があります。
As discussed earlier, the OFDMA mode in [IEEE802.11ax] introduces the possibility of assigning different RUs (time/frequency resources) to users within a PPDU. Several RU sizes are defined in the specification (26, 52, 106, 242, 484, and 996 subcarriers). In addition, the AP can also decide on a Modulation and Coding Scheme (MCS) and grouping of users within a given OFMDA PPDU. Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially:
前述したように、[IEEE802.11ax] の OFDMA モードでは、PPDU 内のユーザーに異なる RU (時間/周波数リソース) を割り当てる可能性が導入されています。仕様ではいくつかの RU サイズが定義されています (26、52、106、242、484、および 996 サブキャリア)。さらに、AP は、変調および符号化方式 (MCS) と、特定の OFMDA PPDU 内のユーザーのグループ化を決定することもできます。このような柔軟性を活用すると、特に次のような、制限されたレイテンシを持つ時間に敏感なアプリケーションをサポートできます。
* in a managed network where stations can be configured to operate under the control of the AP,
* ステーションが AP の制御下で動作するように構成できる管理されたネットワーク内では、
* in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or
* 制御された環境（施設の所有者によって設置されたライセンスのない帯域で動作するデバイスのみが含まれ、他のシステムや無線アクセス技術からの予期せぬ干渉が散発的にのみ発生する環境）、または
* in a deployment where channel and link redundancy is used to reduce the impact of unmanaged devices and interference.
* チャネルとリンクの冗長性を使用して、管理対象外のデバイスと干渉の影響を軽減する展開。
When the network is lightly loaded, it is possible to achieve latencies under 1 ms when Wi-Fi is operated in a contention-based mode (i.e., without OFDMA). It also has been shown that it is possible to achieve 1 ms latencies in a controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019]. Obviously, there are latency, reliability, and capacity trade-offs to be considered. For instance, smaller RUs result in longer transmission durations, which may impact the minimal latency that can be achieved, but the contention latency and randomness elimination in an interference-free environment due to multi-user transmission is a major benefit of the OFDMA mode.
ネットワークの負荷が軽い場合、Wi-Fi が競合ベース モード (OFDMA なし) で動作している場合、遅延を 1 ミリ秒未満に抑えることができます。また、マルチユーザー送信を使用すると (OFDMA 操作によって可能になります)、制御された環境でより高い効率で 1 ミリ秒の遅延を達成できることも示されています [Cavalcanti_2019]。明らかに、遅延、信頼性、容量のトレードオフを考慮する必要があります。たとえば、RU が小さいと送信時間が長くなり、達成できる最小遅延に影響を与える可能性がありますが、マルチユーザー送信による干渉のない環境での競合遅延とランダム性の排除は、OFDMA モードの大きな利点です。
The flexibility to dynamically assign RUs to each transmission also enables the AP to provide frequency diversity, which can help increase reliability.
各送信に RU を動的に割り当てる柔軟性により、AP は周波数ダイバーシティを提供できるようになり、信頼性の向上に役立ちます。
[IEEE802.11be] was the next major 802.11 amendment (after IEEE Std 802.11ax-2021) for operation in the 2.4, 5, and 6 GHz bands. 802.11be includes new PHY and MAC features, and it is targeting extremely high throughput (at least 30 Gbps), as well as enhancements to worst-case latency and jitter. It is also expected to improve the integration with 802.1 TSN to support time-sensitive applications over Ethernet and Wireless LANs.
[IEEE802.11be] は、2.4、5、および 6 GHz 帯域での動作のための次の主要な 802.11 修正 (IEEE Std 802.11ax-2021 の後) です。802.11be には新しい PHY および MAC 機能が含まれており、非常に高いスループット (少なくとも 30 Gbps) と、最悪の場合の遅延とジッターの強化を目標としています。また、802.1 TSN との統合が改善され、イーサネットおよび無線 LAN 上で時間に敏感なアプリケーションをサポートすることも期待されています。
The main features of 802.11be that are relevant to this document include:
このドキュメントに関連する 802.11be の主な機能は次のとおりです。
1. 320 MHz bandwidth and more efficient utilization of non-contiguous spectrum
1. 320 MHz の帯域幅と不連続スペクトルのより効率的な利用
2. Multi-Link Operation (MLO)
2. マルチリンクオペレーション (MLO)
3. QoS enhancements to reduce latency and increase reliability
3. QoS の強化による遅延の削減と信頼性の向上
The 802.11 Real-Time Applications (RTA) Topic Interest Group (TIG) provided detailed information on use cases, issues, and potential solutions to improve support for time-sensitive applications in 802.11. The RTA TIG report [IEEE_doc_11-18-2009-06] was used as input to the 802.11be project scope.
802.11 リアルタイム アプリケーション (RTA) トピック インタレスト グループ (TIG) は、802.11 における時間に敏感なアプリケーションのサポートを向上させるためのユースケース、問題、および潜在的な解決策に関する詳細情報を提供しました。RTA TIG レポート [IEEE_doc_11-18-2009-06] は、802.11be プロジェクト範囲への入力として使用されました。
Improvements for worst-case latency, jitter, and reliability were the main topics identified in the RTA report, which were motivated by applications in gaming, industrial automation, robotics, etc. The RTA report also highlighted the need to support additional TSN capabilities, such as time-aware (802.1Qbv) shaping and packet replication and elimination as defined in 802.1CB.
最悪の場合の遅延、ジッター、信頼性の改善が RTA レポートで特定された主なトピックであり、ゲーム、産業オートメーション、ロボット工学などのアプリケーションによって動機付けられました。RTA レポートでは、時間認識 (802.1Qbv) シェーピングや 802.1CB で定義されているパケットの複製と削除などの追加の TSN 機能をサポートする必要性も強調しました。
IEEE Std 802.11be builds on and enhances 802.11ax capabilities to improve worst case latency and jitter. Some of the enhancement areas are discussed next.
IEEE Std 802.11be は、802.11ax 機能に基づいて構築および強化され、最悪の場合の遅延とジッターを改善します。強化領域のいくつかについては次に説明します。
In addition to the throughput enhancements, 802.11be leverages the trigger-based scheduled operation enabled by 802.11ax to provide efficient and more predictable medium access.
スループットの強化に加えて、802.11be は 802.11ax によって可能になったトリガーベースのスケジュールされた動作を利用して、効率的でより予測可能なメディア アクセスを提供します。
802.11be introduced QoS signaling enhancements, such as an additional QoS characteristics element, that enables stations to provide detailed information about deterministic traffic stream to the AP. This capability helps AP implementations to better support scheduling for deterministic flows.
802.11 では、追加の QoS 特性要素などの QoS シグナリング拡張機能が導入され、ステーションが決定論的なトラフィック ストリームに関する詳細情報を AP に提供できるようになります。この機能は、AP 実装が確定的フローのスケジューリングをより適切にサポートするのに役立ちます。
802.11be introduces new features to improve operation over multiple links and channels. By leveraging multiple links and channels, 802.11be can isolate time-sensitive traffic from network congestion, one of the main causes of large latency variations. In a managed 802.11be network, it should be possible to steer traffic to certain links and channels to isolate time-sensitive traffic from other traffic and help achieve bounded latency. The Multi-Link Operation (MLO) is a major feature in the 802.11be amendment that can enhance latency and reliability by enabling data frames to be duplicated across links.
802.11be には、複数のリンクおよびチャネル上の動作を改善するための新機能が導入されています。802.11be は、複数のリンクとチャネルを活用することで、時間に敏感なトラフィックを、大きな遅延変動の主な原因の 1 つであるネットワークの輻輳から分離できます。管理された 802.11be ネットワークでは、時間に敏感なトラフィックを他のトラフィックから分離し、制限された遅延を実現するために、トラフィックを特定のリンクおよびチャネルに誘導できる必要があります。マルチリンク オペレーション (MLO) は、802.11be 修正の主要な機能であり、リンク間でデータ フレームを複製できるようにすることで遅延と信頼性を向上させることができます。
The IEEE 802.11ad amendment defines PHY and MAC capabilities to enable multi-Gbps throughput in the 60 GHz millimeter wave (mmWave) band. The standard addresses the adverse mmWave signal propagation characteristics and provides directional communication capabilities that take advantage of beamforming to cope with increased attenuation. An overview of the 802.11ad standard can be found in [Nitsche_2015].
IEEE 802.11ad 修正では、60 GHz ミリ波 (mmWave) 帯域でマルチ Gbps スループットを可能にする PHY および MAC 機能が定義されています。この規格は、不利なミリ波信号伝播特性に対処し、増加した減衰に対処するためにビームフォーミングを利用する指向性通信機能を提供します。802.11ad 標準の概要については、[Nitsche_2015] を参照してください。
The IEEE 802.11ay is currently developing enhancements to the 802.11ad standard to enable the next generation mmWave operation targeting 100 Gbps throughput. Some of the main enhancements in 802.11ay include MIMO, channel bonding, improved channel access, and beamforming training. An overview of the 802.11ay capabilities can be found in [Ghasempour_2017].
IEEE 802.11ay は現在、100 Gbps スループットを目標とする次世代ミリ波動作を可能にする 802.11ad 標準の拡張機能を開発中です。802.11ay の主な機能強化には、MIMO、チャネル ボンディング、チャネル アクセスの改善、ビームフォーミング トレーニングなどがあります。802.11ay 機能の概要については、[Ghasempour_2017] を参照してください。
The high-data rates achievable with 802.11ad and 802.11ay can significantly reduce latency down to microsecond levels. Limited interference from legacy and other unlicensed devices in 60 GHz is also a benefit. However, the directionality and short range typical in mmWave operation impose new challenges such as the overhead required for beam training and blockage issues, which impact both latency and reliability. Therefore, it is important to understand the use case and deployment conditions in order to properly apply and configure 802.11ad/ay networks for time-sensitive applications.
802.11ad および 802.11ay で実現可能な高速データ レートにより、遅延をマイクロ秒レベルまで大幅に短縮できます。60 GHz ではレガシー デバイスやその他のライセンスのないデバイスからの干渉が制限されることも利点です。ただし、ミリ波動作に特有の指向性と短距離により、ビーム トレーニングに必要なオーバーヘッドや妨害問題などの新たな課題が生じ、遅延と信頼性の両方に影響を及ぼします。したがって、時間に敏感なアプリケーションに 802.11ad/ay ネットワークを適切に適用して構成するには、ユースケースと導入条件を理解することが重要です。
The 802.11ad standard includes a scheduled access mode in which the central controller, after contending and reserving the channel for a dedicated period, can allocate to stations contention-free service periods. This scheduling capability is also available in 802.11ay, and it is one of the mechanisms that can be used to provide bounded latency to time-sensitive data flows in interference-free scenarios. An analysis of the theoretical latency bounds that can be achieved with 802.11ad service periods is provided in [Cavalcanti_2019].
802.11ad 規格にはスケジュールされたアクセス モードが含まれており、中央コントローラが専用期間のチャネルを競合して予約した後、ステーションに競合のないサービス期間を割り当てることができます。このスケジューリング機能は 802.11ay でも利用でき、干渉のないシナリオで時間に敏感なデータ フローに制限された遅延を提供するために使用できるメカニズムの 1 つです。802.11ad サービス期間で達成できる理論上の遅延限界の分析は、[Cavalcanti_2019] で提供されています。
IEEE Std 802.15.4 TSCH was the first IEEE radio specification aimed directly at industrial IoT applications, for use in process control loops and monitoring. It was used as a base for the major industrial wireless process control standards, Wireless Highway Addressable Remote Transducer Protocol (HART) and ISA100.11a.
IEEE Std 802.15.4 TSCH は、プロセス制御ループとモニタリングでの使用を目的とした、産業用 IoT アプリケーションを直接目的とした最初の IEEE 無線仕様です。これは、主要な産業用ワイヤレス プロセス制御標準であるワイヤレス ハイウェイ アドレス可能リモート トランスデューサ プロトコル (HART) および ISA100.11a のベースとして使用されました。
While the MAC/PHY standards enable the relatively slow rates used in process control (typically in the order of 4-5 per second), the technology is not suited for the faster periods used in factory automation and motion control (1 to 10 ms).
MAC/PHY 標準では、プロセス制御で使用される比較的遅い速度 (通常は 1 秒あたり 4 ～ 5 程度) が可能ですが、このテクノロジーは工場オートメーションやモーション制御で使用される高速な速度 (1 ～ 10 ミリ秒) には適していません。
The IEEE 802.15.4 Task Group has been driving the development of low-power, low-cost radio technology. The IEEE 802.15.4 Physical (PHY) layer has been designed to support demanding low-power scenarios targeting the use of unlicensed bands, both the 2.4 GHz and sub-GHz Industrial, Scientific and Medical (ISM) bands. This has imposed requirements in terms of frame size, data rate, and bandwidth to achieve reduced collision probability, reduced packet error rate, and acceptable range with limited transmission power. The PHY layer supports frames of up to 127 bytes. The Medium Access Control (MAC) sublayer overhead is in the order of 10-20 bytes, leaving about 100 bytes to the upper layers. IEEE 802.15.4 uses spread spectrum modulation such as the Direct Sequence Spread Spectrum (DSSS).
IEEE 802.15.4 タスク グループは、低電力、低コストの無線技術の開発を推進してきました。IEEE 802.15.4 物理 (PHY) レイヤーは、2.4 GHz とサブ GHz の産業、科学、医療 (ISM) 帯域の両方であるライセンス不要の帯域の使用を対象とした、要求の厳しい低電力シナリオをサポートするように設計されています。これにより、制限された送信電力で衝突確率の低減、パケット誤り率の低減、および許容可能な範囲を達成するために、フレーム サイズ、データ レート、および帯域幅に関する要件が課せられました。PHY 層は、最大 127 バイトのフレームをサポートします。メディア アクセス コントロール (MAC) サブレイヤのオーバーヘッドは 10 ～ 20 バイト程度で、約 100 バイトが上位レイヤに残ります。IEEE 802.15.4 は、ダイレクト シーケンス スペクトラム拡散 (DSSS) などのスペクトラム拡散変調を使用します。
The Time-Slotted Channel Hopping (TSCH) mode was added to the 2015 revision of the IEEE 802.15.4 standard [IEEE802.15.4]. TSCH is targeted at the embedded and industrial world, where reliability, energy consumption, and cost drive the application space.
タイムスロット チャネル ホッピング (TSCH) モードは、IEEE 802.15.4 標準 [IEEE802.15.4] の 2015 年改訂版に追加されました。TSCH は、信頼性、エネルギー消費、コストがアプリケーション分野を左右する組み込みおよび産業界をターゲットとしています。
Building on IEEE 802.15.4, TSN on low-power constrained wireless networks has been partially addressed by ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART]. Both technologies involve a central controller that computes redundant paths for industrial process control traffic over a TSCH mesh. Moreover, ISA100.11a introduces IPv6 capabilities [RFC8200] with a link-local address for the join process and a global unicast address for later exchanges, but the IPv6 traffic typically ends at a local application gateway and the full power of IPv6 for end-to-end communication is not enabled.
IEEE 802.15.4 に基づいて構築された、低電力制約のあるワイヤレス ネットワーク上の TSN は、ISA100.11a [ISA100.11a] および WirelessHART [WirelessHART] によって部分的に対処されています。どちらのテクノロジーにも、TSCH メッシュ上の産業プロセス制御トラフィックの冗長パスを計算する中央コントローラーが含まれます。さらに、ISA100.11a では、参加プロセス用のリンクローカル アドレスとその後の交換用のグローバル ユニキャスト アドレスを備えた IPv6 機能 [RFC8200] が導入されていますが、IPv6 トラフィックは通常、ローカル アプリケーション ゲートウェイで終了し、エンドツーエンド通信における IPv6 のフル機能は有効になっていません。
At the IETF, the 6TiSCH Working Group [TiSCH] has enabled distributed routing and scheduling to exploit the deterministic access capabilities provided by TSCH for IPv6. The group designed the essential mechanisms, the 6TiSCH Operation (6top) sublayer and the Scheduling Functions (SFs), to enable the management plane operation while ensuring IPv6 is supported.
IETF では、6TiSCH ワーキング グループ [TiSCH] が、IPv6 の TSCH によって提供される決定論的アクセス機能を活用する分散ルーティングとスケジューリングを有効にしました。同グループは、IPv6 を確実にサポートしながら管理プレーンの動作を可能にするために、重要なメカニズムである 6TiSCH オペレーション (6top) サブレイヤとスケジューリング機能 (SF) を設計しました。
* The 6top Protocol (6P) is defined in [RFC8480] and provides a pairwise negotiation mechanism to the control plane operation. The protocol supports agreement on a schedule between neighbors, enabling distributed scheduling.
* 6top プロトコル (6P) は [RFC8480] で定義されており、コントロール プレーンの動作にペアワイズ ネゴシエーション メカニズムを提供します。このプロトコルは、近隣者間のスケジュールに関する合意をサポートし、分散スケジューリングを可能にします。
* 6P goes hand in hand with an SF, the policy that decides how to maintain cells and trigger 6P transactions. The Minimal Scheduling Function (MSF) [RFC9033] is the default SF defined by the 6TiSCH WG.
* 6P は、セルを維持し、6P トランザクションをトリガーする方法を決定するポリシーである SF と連携します。Minimal Scheduling Function (MSF) [RFC9033] は、6TiSCH WG によって定義されたデフォルトの SF です。
* With these mechanisms, 6TiSCH can establish Layer 2 links between neighboring nodes and support best-effort traffic. The Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] provides the routing structure, enabling the 6TiSCH devices to establish the links with well-connected neighbors, thus forming the acyclic network graphs.
* これらのメカニズムにより、6TiSCH は隣接ノード間にレイヤ 2 リンクを確立し、ベストエフォート トラフィックをサポートできます。低電力および損失の多いネットワーク用ルーティング プロトコル (RPL) [RFC6550] はルーティング構造を提供し、6TiSCH デバイスが適切に接続された隣接デバイスとのリンクを確立できるようにして、非周期ネットワーク グラフを形成します。
In 6TiSCH, a Track is the concept of a recovery graph in the RAW architecture applied to wireless. A Track can follow a simple sequence of relay nodes, or it can be structured as a more complex Destination-Oriented Directed Acyclic Graph (DODAG) to a unicast destination. Along a Track, 6TiSCH nodes reserve the resources to enable the efficient transmission of packets while aiming to optimize certain properties such as reliability and ensure small jitter or bounded latency. The Track structure enables Layer 2 forwarding schemes, reducing the overhead of making routing decisions at Layer 3.
6TiSCH では、トラックはワイヤレスに適用される RAW アーキテクチャの回復グラフの概念です。トラックは、中継ノードの単純なシーケンスに従うことも、ユニキャスト宛先へのより複雑な宛先指向有向非巡回グラフ (DODAG) として構造化することもできます。トラックに沿って、6TiSCH ノードは、信頼性などの特定の特性を最適化し、小さなジッターや制限された遅延を確保することを目指しながら、パケットの効率的な送信を可能にするリソースを予約します。トラック構造により、レイヤ 2 転送スキームが有効になり、レイヤ 3 でルーティングを決定するオーバーヘッドが削減されます。
The 6TiSCH architecture [RFC9030] identifies different models to schedule resources along so-called Tracks (see Section 5.2.1), exploiting the TSCH schedule structure; however, the focus in 6TiSCH is on best-effort traffic, and the group was never chartered to produce standards work related to Tracks.
6TiSCH アーキテクチャ [RFC9030] は、TSCH スケジュール構造を利用して、いわゆるトラック (セクション 5.2.1 を参照) に沿ってリソースをスケジュールするためのさまざまなモデルを識別します。ただし、6TiSCH ではベストエフォート型トラフィックに重点が置かれており、このグループはトラックに関連する標準作業を作成するために認可されたことはありません。
There are several works that can be used to complement the overview provided in this document. For example, [vilajosana21] provides a detailed description of the 6TiSCH protocols, how they are linked together, and how they are integrated with other standards like RPL and 6Lo.
この文書で提供される概要を補完するために使用できる著作物がいくつかあります。たとえば、[vilajosana21] では、6TiSCH プロトコル、それらがどのようにリンクされているか、および RPL や 6Lo などの他の標準とどのように統合されているかについて詳しく説明しています。
As a core technique in IEEE 802.15.4, TSCH splits time in multiple time slots that repeat over time. Each device has its own perspective of when the send or receive occurs and on which channel the transmission happens. This constitutes the device's slotframe, where the channel and destination of a transmission by this device are a function of time. The overall aggregation of all the slotframes of all the devices constitutes a time/frequency matrix with at most one transmission in each cell of the matrix (see more in Section 5.3.1.4).
IEEE 802.15.4 の中核技術として、TSCH は時間を複数のタイム スロットに分割し、時間の経過とともに繰り返します。各デバイスには、送信または受信がいつ行われるか、どのチャネルで送信が行われるかについて独自の観点があります。これはデバイスのスロットフレームを構成し、このデバイスによる送信のチャネルと宛先は時間の関数です。すべてのデバイスのすべてのスロットフレームの全体的な集合体は、マトリックスの各セルで最大 1 つの送信を含む時間/周波数マトリックスを構成します (詳細はセクション 5.3.1.4 を参照)。
The IEEE 802.15.4 TSCH standard does not define any scheduling mechanism but only provides the architecture that establishes a slotted structure that can be managed by a proper schedule. This schedule represents the possible communications of a node with its neighbors and is managed by a Scheduling Function such as the Minimal Scheduling Function (MSF) [RFC9033]. In MSF, each cell in the schedule is identified by its slotOffset and channelOffset coordinates. A cell's timeSlot offset indicates its position in time, relative to the beginning of the slotframe. A cell's channel offset is an index that maps to a frequency at each iteration of the slotframe. Each packet exchanged between neighbors happens within one cell. The size of a cell is a timeSlot duration, between 10 to 15 milliseconds. An Absolute Slot Number (ASN) indicates the number of slots elapsed since the network started. It increments at every slot. This is a 5-byte counter that can support networks running for more than 300 years without wrapping (assuming a 10 ms timeSlot). Channel hopping provides increased reliability to multipath fading and external interference. It is handled by TSCH through a channel-hopping sequence referred to as macHopSeq in the IEEE 802.15.4 specification.
IEEE 802.15.4 TSCH 標準では、スケジューリング メカニズムは定義されておらず、適切なスケジュールによって管理できるスロット構造を確立するアーキテクチャのみが提供されています。このスケジュールは、ノードが近隣ノードと通信できる可能性を表し、Minimal Scheduling Function (MSF) [RFC9033] などのスケジューリング関数によって管理されます。MSF では、スケジュール内の各セルは、slotOffset 座標と channelOffset 座標によって識別されます。セルのタイムスロット オフセットは、スロットフレームの先頭を基準とした時間的な位置を示します。セルのチャネル オフセットは、スロットフレームの各反復で周波数にマッピングされるインデックスです。近隣間で交換される各パケットは 1 つのセル内で発生します。セルのサイズは、10 ～ 15 ミリ秒のタイムスロット期間です。絶対スロット番号 (ASN) は、ネットワークが開始されてから経過したスロットの数を示します。スロットごとに増加します。これは、ラップなしで 300 年以上実行されるネットワークをサポートできる 5 バイトのカウンターです (10 ミリ秒のタイムスロットを想定)。チャネル ホッピングにより、マルチパス フェージングや外部干渉に対する信頼性が向上します。これは、IEEE 802.15.4 仕様で macHopSeq と呼ばれるチャネル ホッピング シーケンスを通じて TSCH によって処理されます。
The Time-Frequency Division Multiple Access provided by TSCH enables the orchestration of traffic flows, spreading them in time and frequency, and hence enabling an efficient management of the bandwidth utilization. Such efficient bandwidth utilization can be combined with OFDM modulations also supported by the IEEE 802.15.4 standard [IEEE802.15.4] since the 2015 version.
TSCH が提供する時間周波数分割多元接続により、トラフィック フローのオーケストレーションが可能になり、トラフィック フローを時間と周波数で分散できるため、帯域幅使用率の効率的な管理が可能になります。このような効率的な帯域幅の利用は、2015 年バージョン以降、IEEE 802.15.4 標準 [IEEE802.15.4] でもサポートされている OFDM 変調と組み合わせることができます。
TSCH networks operate in ISM bands in which the spectrum is shared by different coexisting technologies. Regulations such as the FCC, ETSI, and ARIB impose duty cycle regulations to limit the use of the bands, but interference may still constrain the probability of delivering a packet. Part of these reliability challenges are addressed at the MAC layer by introducing redundancy and diversity, thanks to channel hopping, scheduling, and ARQ policies. Yet, the MAC layer operates with a 1-hop vision, being limited to local actions to mitigate underperforming links.
TSCH ネットワークは、共存するさまざまなテクノロジーによってスペクトルが共有される ISM 帯域で動作します。FCC、ETSI、ARIB などの規制では、帯域の使用を制限するためにデューティ サイクル規制が課されていますが、それでも干渉によってパケットの配信確率が制限される可能性があります。これらの信頼性の課題の一部は、チャネル ホッピング、スケジューリング、ARQ ポリシーのおかげで冗長性と多様性を導入することで MAC 層で対処されます。ただし、MAC 層は 1 ホップのビジョンで動作し、パフォーマンスの低いリンクを軽減するためのローカル アクションに限定されます。
In the 6TiSCH architecture [RFC9030], a Track is the concept of a DetNet architecture protection path applied to 6TiSCH networks. A Track can be structured as a Destination-Oriented Directed Acyclic Graph (DODAG) to a destination for unicast traffic. Along a Track, 6TiSCH nodes reserve the resources to enable the efficient transmission of packets while aiming to optimize certain properties such as reliability and ensure small jitter or bounded latency. The Track structure enables Layer 2 forwarding schemes, reducing the overhead of making routing decisions at Layer 3.
6TiSCH アーキテクチャ [RFC9030] では、トラックは 6TiSCH ネットワークに適用される DetNet アーキテクチャ保護パスの概念です。トラックは、ユニキャスト トラフィックの宛先への宛先指向有向非巡回グラフ (DODAG) として構造化できます。トラックに沿って、6TiSCH ノードは、信頼性などの特定の特性を最適化し、小さなジッターや制限された遅延を確保することを目指しながら、パケットの効率的な送信を可能にするリソースを予約します。トラック構造により、レイヤ 2 転送スキームが有効になり、レイヤ 3 でルーティングを決定するオーバーヘッドが削減されます。
Serial Tracks can be understood as the concatenation of cells or bundles along a routing path from a source towards a destination. The serial Track concept is analogous to the circuit concept where resources are chained into a multi-hop topology; see more in Section 5.2.1.2 on how that is used in the data plane to forward packets.
シリアル トラックは、ソースから宛先に向かうルーティング パスに沿ったセルまたはバンドルの連結として理解できます。シリアル トラックの概念は、リソースがマルチホップ トポロジにチェーンされる回路の概念に似ています。データ プレーンでパケットを転送するためにこれがどのように使用されるかについては、セクション 5.2.1.2 を参照してください。
Whereas scheduling ensures reliable delivery in bounded time along any Track, high availability requires the application of PREOF functions along a more complex DODAG Track structure. A DODAG has forking and joining nodes where concepts like replication and elimination can be exploited. Spatial redundancy increases the overall energy consumption in the network but significantly improves the availability of the network as well as the packet delivery ratio. A Track may also branch off and rejoin, for the purpose of so-called Packet Replication and Elimination (PRE), over non-congruent branches. PRE may be used to complement Layer 2 ARQ and receiver-end ordering to complete/extend the PREOF functions. This enables meeting industrial expectations of packet delivery within bounded delay over a Track that includes wireless links, even when the Track extends beyond the 6TiSCH network.
スケジューリングにより、任意のトラックに沿って限られた時間内で信頼性の高い配信が保証されますが、高可用性を実現するには、より複雑な DODAG トラック構造に沿った PREOF 機能の適用が必要です。DODAG には分岐ノードと結合ノードがあり、複製や削除などの概念を活用できます。空間冗長性により、ネットワーク全体のエネルギー消費量が増加しますが、ネットワークの可用性とパケット配信率が大幅に向上します。トラックは、いわゆるパケット複製および削除 (PRE) の目的で、一致しない分岐を介して分岐したり再結合したりすることもあります。PRE は、PREOF 機能を完了/拡張するために、レイヤ 2 ARQ および受信機側の順序付けを補完するために使用できます。これにより、トラックが 6TiSCH ネットワークを超えて拡張されている場合でも、ワイヤレス リンクを含むトラック上で制限された遅延内でパケット配信が行われるという業界の期待に応えることができます。
The RAW recovery graph described in the RAW architecture [RFC9912] inherits directly from that model. RAW extends the graph beyond a DODAG as long as a given packet cannot loop within the Track.
RAW アーキテクチャ [RFC9912] で説明されている RAW 回復グラフは、そのモデルを直接継承しています。RAW は、特定のパケットがトラック内でループできない限り、グラフを DODAG を超えて拡張します。
+-----+
| IoT |
| G/W |
+-----+
^ <---- Elimination
| |
Track branch | |
+-------+ +--------+ Subnet backbone
| |
+--|--+ +--|--+
| | | Backbone | | | Backbone
o | | | router | | | router
+--/--+ +--|--+
o / o o---o----/ o
o o---o--/ o o o o o
o \ / o o LLN o
o v <---- Replication
o
Figure 1: End-to-End Deterministic Track
図 1: エンドツーエンドの確定的な追跡
In Figure 1, a Track is laid out from a field device in a 6TiSCH network to an IoT gateway that is located on an IEEE 802.1 TSN backbone.
図 1 では、6TiSCH ネットワーク内のフィールド デバイスから IEEE 802.1 TSN バックボーンにある IoT ゲートウェイまでトラックがレイアウトされています。
The Replication function in the field device sends a copy of each packet over two different branches, and a PCE schedules each hop of both branches so that the two copies arrive in due time at the gateway. In case of a loss on one branch, hopefully the other copy of the packet still makes it in due time. If two copies make it to the IoT gateway, the Elimination function in the gateway ignores the extra packet and presents only one copy to upper layers.
フィールド デバイスのレプリケーション機能は、各パケットのコピーを 2 つの異なるブランチ経由で送信し、PCE は 2 つのコピーが予定どおりにゲートウェイに到着するように両方のブランチの各ホップをスケジュールします。1 つのブランチで損失が発生した場合でも、パケットのもう 1 つのコピーが時間内に到着することが期待されます。2 つのコピーが IoT ゲートウェイに到達した場合、ゲートウェイのエリミネーション機能は余分なパケットを無視し、1 つのコピーだけを上位層に提示します。
At each 6TiSCH hop along the Track, the PCE may schedule more than one timeSlot for a packet, so as to support Layer 2 retries (ARQ). It is also possible for the field device to only use the second branch if sending over the first branch fails.
トラックに沿った各 6TiSCH ホップで、PCE はレイヤ 2 再試行 (ARQ) をサポートするために、パケットに対して複数のタイムスロットをスケジュールできます。最初のブランチでの送信が失敗した場合、フィールド デバイスが 2 番目のブランチのみを使用することも可能です。
In current deployments, a TSCH Track does not necessarily support PRE but is systematically multipath. This means that a Track is scheduled so as to ensure that each hop has at least two forwarding solutions, and the forwarding decision is to try the preferred one and use the other in case of Layer 2 transmission failure as detected by ARQ.
現在の展開では、TSCH トラックは必ずしも PRE をサポートしているわけではありませんが、システム的にはマルチパスです。これは、各ホップに少なくとも 2 つの転送ソリューションがあることを保証するようにトラックがスケジュールされ、転送の決定は、優先される方を試し、ARQ によって検出されたレイヤ 2 送信障害の場合にはもう一方を使用することを意味します。
Methods to implement complex Tracks are described in [RFC9914] and complemented by extensions to the RPL routing protocol in [NSA-EXT] for best-effort traffic, but a centralized routing technique such as one promoted in DetNet is still missing.
複雑なトラックを実装する方法は [RFC9914] で説明されており、ベストエフォート トラフィック用の [NSA-EXT] の RPL ルーティング プロトコルの拡張によって補完されていますが、DetNet で推進されているような集中ルーティング技術はまだ存在していません。
Section 4.4 of the 6TiSCH architecture [RFC9030] describes four approaches to manage the TSCH schedule of the Low-Power and Lossy Network (LLN) nodes: static scheduling, neighbor-to-neighbor scheduling, remote monitoring and scheduling management, and hop-by-hop scheduling. The Track operation for DetNet corresponds to a remote monitoring and scheduling management by a PCE.
6TiSCH アーキテクチャ [RFC9030] のセクション 4.4 では、低電力および損失の多いネットワーク (LLN) ノードの TSCH スケジュールを管理するための 4 つのアプローチ、つまり静的スケジューリング、ネイバーツーネイバースケジューリング、リモートモニタリングとスケジューリング管理、およびホップバイホップスケジューリングについて説明しています。DetNet の Track 操作は、PCE による遠隔監視とスケジュール管理に対応します。
In the 6TiSCH architecture [RFC9030], forwarding is the per-packet operation that allows a packet to be delivered to a next hop or an upper layer in a node. Forwarding is based on preexisting state that was installed as a result of the routing computation of a Track by a PCE. The 6TiSCH architecture supports three different forwarding models: GMPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF), and IPv6 Forwarding (6F), which is the classical IP operation [RFC9030]. The DetNet case relates to the Track Forwarding operation under the control of a PCE.
6TiSCH アーキテクチャ [RFC9030] では、転送はパケットごとの操作であり、パケットを次のホップまたはノードの上位層に配信できるようにします。転送は、PCE によるトラックのルーティング計算の結果としてインストールされた既存の状態に基づきます。6TiSCH アーキテクチャは、GMPLS トラック転送 (TF)、6LoWPAN フラグメント転送 (FF)、および古典的な IP 動作 [RFC9030] である IPv6 転送 (6F) の 3 つの異なる転送モデルをサポートします。DetNet のケースは、PCE の制御下でのトラック転送操作に関連しています。
A Track is a unidirectional path between a source and a destination. Time and frequency resources called cells (see Section 5.3.1.4) are allocated to enable the forwarding operation along the Track. In a Track cell, the normal operation of IEEE 802.15.4 ARQ usually happens, though the acknowledgment may be omitted in some cases, for instance, if there is no scheduled cell for a retry.
トラックは、ソースと宛先の間の単方向パスです。トラックに沿った転送動作を可能にするために、セルと呼ばれる時間および周波数リソース (セクション 5.3.1.4 を参照) が割り当てられます。Track セルでは、通常、IEEE 802.15.4 ARQ の通常の動作が行われますが、場合によっては、たとえば、再試行が予定されているセルがない場合など、確認応答が省略されることがあります。
Track Forwarding is the simplest and fastest operation. A bundle of cells set to receive (RX-cells) is uniquely paired to a bundle of cells that are set to transmit (TX-cells), representing a Layer 2 forwarding state that can be used regardless of the network-layer protocol. This model can effectively be seen as a Generalized Multiprotocol Label Switching (GMPLS) operation in that the information used to switch a frame is not an explicit label but is rather related to other properties about the way the packet was received (a particular cell, in the case of 6TiSCH). As a result, as long as the TSCH MAC (and Layer 2 security) accepts a frame, that frame can be switched regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate protocol such as WirelessHART or ISA100.11a.
トラックの転送は、最も簡単かつ高速な操作です。受信するように設定されたセルのバンドル (RX セル) は、送信するように設定されたセルのバンドル (TX セル) と一意にペアリングされ、ネットワーク層プロトコルに関係なく使用できるレイヤー 2 転送状態を表します。このモデルは、フレームのスイッチングに使用される情報が明示的なラベルではなく、パケットの受信方法 (6TiSCH の場合は特定のセル) に関する他のプロパティに関連しているという点で、実質的に一般化マルチプロトコル ラベル スイッチング (GMPLS) 動作とみなすことができます。その結果、TSCH MAC (およびレイヤー 2 セキュリティ) がフレームを受け入れる限り、IPv6 パケット、6LoWPAN フラグメント、または WirelessHART や ISA100.11a などの代替プロトコルからのフレームなど、プロトコルに関係なく、そのフレームを切り替えることができます。
A data frame that is forwarded along a Track normally has a destination MAC address that is set to broadcast (or a multicast address, depending on MAC support). This way, the MAC layer in the intermediate nodes accepts the incoming frame, and 6top switches it without incurring a change in the MAC header. In the case of IEEE 802.15.4, this effectively means that the address is broadcast, so that the short address for the destination of the frame is set to 0xFFFF along the Track.
トラックに沿って転送されるデータ フレームには、通常、ブロードキャスト (または MAC サポートに応じてマルチキャスト アドレス) に設定された宛先 MAC アドレスがあります。このようにして、中間ノードの MAC 層は受信フレームを受け入れ、6top は MAC ヘッダーを変更せずにフレームを切り替えます。IEEE 802.15.4 の場合、これは実質的にアドレスがブロードキャストされることを意味するため、フレームの宛先の短縮アドレスはトラックに沿って 0xFFFF に設定されます。
A Track is thus formed end to end as a succession of paired bundles: a receive bundle from the previous hop and a transmit bundle to the next hop along the Track. A cell in such a bundle belongs to one Track at most. For a given iteration of the device schedule, the effective channel of the cell is obtained by adding a pseudorandom number to the channelOffset of the cell, which results in a rotation of the frequency that was used for transmission. The bundles may be computed so as to accommodate both variable rates and retransmissions, so they might not be fully used at a given iteration of the schedule. The 6TiSCH architecture provides additional means to avoid waste of cells as well as overflows in the transmit bundle, as described in the following paragraphs.
したがって、トラックは、一連のペアのバンドル、つまりトラックに沿った前のホップからの受信バンドルと次のホップへの送信バンドルとしてエンドツーエンドで形成されます。このようなバンドル内のセルは、最大でも 1 つのトラックに属します。デバイス スケジュールの所定の反復では、セルの有効チャネルは、セルの ChannelOffset に擬似乱数を追加することによって取得されます。これにより、送信に使用された周波数が回転します。バンドルは、可変レートと再送信の両方に対応できるように計算されるため、スケジュールの特定の繰り返しでは完全には使用されない可能性があります。6TiSCH アーキテクチャは、次の段落で説明するように、セルの無駄や送信バンドル内のオーバーフローを回避するための追加手段を提供します。
On one hand, a TX-cell that is not needed for the current iteration may be reused opportunistically on a per-hop basis for routed packets. When all of the frames that were received for a given Track are effectively transmitted, any available TX-cell for that Track can be reused for upper-layer traffic for which the next-hop router matches the next hop along the Track. In that case, the cell that is being used is effectively a TX-cell from the Track, but the short address for the destination is that of the next-hop router. As a result, a frame that is received in an RX-cell of a Track with a destination MAC address set to this node as opposed to broadcast must be extracted from the Track and delivered to the upper layer (a frame with an unrecognized MAC address is dropped at the lower MAC layer and thus is not received at the 6top sublayer).
一方で、現在の反復に必要のない TX セルは、ルーティングされたパケットのホップごとに機会を見て再利用される可能性があります。特定のトラックで受信されたすべてのフレームが効果的に送信されると、そのトラックで使用可能な TX セルは、ネクスト ホップ ルータがトラックに沿ったネクスト ホップと一致する上位層のトラフィックに再利用できます。この場合、使用されているセルは事実上、トラックからの TX セルですが、宛先の短縮アドレスは次ホップ ルーターのアドレスです。その結果、ブロードキャストとは対照的に、宛先 MAC アドレスがこのノードに設定されたトラックの RX セルで受信されたフレームは、トラックから抽出されて上位層に配信される必要があります (認識されない MAC アドレスを持つフレームは下位 MAC 層でドロップされるため、6top サブ層では受信されません)。
On the other hand, it might happen that there are not enough TX-cells in the transmit bundle to accommodate the Track traffic, for instance, if more retransmissions are needed than provisioned. In that case, the frame can be placed for transmission in the bundle that is used for Layer 3 traffic towards the next hop along the Track as long as it can be routed by the upper layer, that is, typically, if the frame transports an IPv6 packet. The MAC address should be set to the next-hop MAC address to avoid confusion. As a result, a frame that is received over a Layer 3 bundle may be in fact associated with a Track. In a classical IP link such as an Ethernet, off-Track traffic is typically in excess over reservation to be routed along the non-reserved path based on its QoS setting. However, with 6TiSCH, since the use of the Layer 3 bundle may be due to transmission failures, it makes sense for the receiver to recognize a frame that should be re-Tracked and to place it back on the appropriate bundle if possible. A frame should be re-Tracked if the per-hop-behavior group indicated in the Differentiated Services field in the IPv6 header is set to deterministic forwarding, as discussed in Section 5.3.1.1. A frame is re-Tracked by scheduling it for transmission over the transmit bundle associated with the Track, with the destination MAC address set to broadcast.
一方、プロビジョニングされたよりも多くの再送信が必要な場合など、トラック トラフィックに対応するのに十分な TX セルが送信バンドルにない場合があります。その場合、フレームは、上位層によってルーティングできる限り、つまり、通常はフレームが IPv6 パケットを転送する場合に限り、トラックに沿った次のホップに向かうレイヤ 3 トラフィックに使用されるバンドル内に送信用に配置できます。混乱を避けるために、MAC アドレスはネクストホップ MAC アドレスに設定する必要があります。その結果、レイヤ 3 バンドル経由で受信されたフレームは、実際にはトラックに関連付けられている可能性があります。イーサネットなどの従来の IP リンクでは、オフトラック トラフィックは通常、QoS 設定に基づいて非予約パスに沿ってルーティングされる予約を超過します。ただし、6TiSCH では、送信障害が原因でレイヤ 3 バンドルが使用される可能性があるため、受信機が再追跡する必要があるフレームを認識し、可能であればそれを適切なバンドルに戻すことが理にかなっています。セクション5.3.1.1で説明されているように、IPv6ヘッダーのDifferentiated Servicesフィールドに示されているホップごとの動作グループが決定論的転送に設定されている場合、フレームは再追跡される必要があります。フレームは、宛先 MAC アドレスをブロードキャストに設定して、トラックに関連付けられた送信バンドルを介して送信するようにスケジュールすることによって再追跡されます。
"An Overview of Operations, Administration, and Maintenance (OAM) Tools" [RFC7276] provides an overview of the existing tooling for OAM [RFC6291]. Tracks are complex paths and new tooling is necessary to manage them, with respect to load control, timing, and the Packet Replication and Elimination Functions (PREF).
「運用、管理、保守 (OAM) ツールの概要」[RFC7276] は、OAM [RFC6291] の既存のツールの概要を提供します。トラックは複雑なパスであり、負荷制御、タイミング、パケット レプリケーションおよびエリミネーション機能 (PREF) に関して、トラックを管理するには新しいツールが必要です。
An example of such tooling can be found in the context of Bit Index Explicit Replication (BIER) [RFC8279] and, more specifically, BIER Traffic Engineering (BIER-TE) [RFC9262].
このようなツールの例は、Bit Index Explicit Replication (BIER) [RFC8279]、より具体的には BIER Traffic Engineering (BIER-TE) [RFC9262] のコンテキストで見つけることができます。
In the RAW context, low-power reliable networks should address non-critical control scenarios such as Class 2 and monitoring scenarios such as Class 4, as defined by [RFC5673]. As a low-power technology targeting industrial scenarios, radio transducers provide low data rates (typically between 50 kbps to 250 kbps) and robust modulations to trade off performance for reliability. TSCH networks are organized in mesh topologies and connected to a backbone. Latency in the mesh network is mainly influenced by propagation aspects such as interference. ARQ methods and redundancy techniques such as replication and elimination should be studied to provide the needed performance to address deterministic scenarios.
RAW のコンテキストでは、低電力の信頼性の高いネットワークは、[RFC5673] で定義されているように、クラス 2 などの非クリティカルな制御シナリオやクラス 4 などの監視シナリオに対処する必要があります。産業用シナリオを対象とした低電力テクノロジーとして、無線トランスデューサは、信頼性とパフォーマンスをトレードオフする低いデータ レート (通常は 50 kbps ～ 250 kbps) と堅牢な変調を提供します。TSCH ネットワークはメッシュ トポロジで編成され、バックボーンに接続されます。メッシュ ネットワークの遅延は、主に干渉などの伝播の側面によって影響されます。決定論的なシナリオに対処するために必要なパフォーマンスを提供するには、ARQ 手法と複製や削除などの冗長技術を検討する必要があります。
Nodes in a TSCH network are tightly synchronized. This enables building the slotted structure and ensures efficient utilization of resources thanks to proper scheduling policies. Scheduling is key to orchestrate the resources that different nodes in a Track or a path are using. Slotframes can be split in resource blocks, reserving the needed capacity to certain flows. Periodic and bursty traffic can be handled independently in the schedule, using active and reactive policies and taking advantage of overprovisioned cells. Along a Track (see Section 5.2.1), resource blocks can be chained so nodes in previous hops transmit their data before the next packet comes. This provides a tight control of latency along a Track. Collision loss is avoided for best-effort traffic by overprovisioning resources, giving time to the management plane of the network to dedicate more resources if needed.
TSCH ネットワーク内のノードは厳密に同期されています。これにより、スロット構造の構築が可能になり、適切なスケジューリング ポリシーによりリソースの効率的な利用が保証されます。スケジュールは、トラックまたはパス内のさまざまなノードが使用しているリソースを調整するための鍵です。スロットフレームはリソース ブロックに分割して、特定のフローに必要な容量を確保できます。定期的およびバースト的なトラフィックは、アクティブおよびリアクティブ ポリシーを使用し、オーバープロビジョニングされたセルを利用して、スケジュール内で独立して処理できます。トラック (セクション 5.2.1 を参照) に沿って、リソース ブロックをチェーンして、前のホップのノードが次のパケットが到着する前にデータを送信できるようにすることができます。これにより、トラックに沿ったレイテンシーを厳密に制御できます。ベストエフォート型トラフィックでは、リソースをオーバープロビジョニングし、必要に応じてより多くのリソースを割り当てる時間をネットワークの管理プレーンに与えることで、衝突損失が回避されます。
When considering end-to-end communication over TSCH, a 6TiSCH device usually does not place a request for bandwidth between itself and another device in the network. Rather, an Operation Control System (OCS) invoked through a Human/Machine Interface (HMI) provides the traffic specification (in particular, in terms of latency, reliability, and the end nodes) to a PCE. With this, the PCE computes a Track between the end nodes and provisions every hop in the Track with per-flow state that describes the per-hop operation for a given packet, the corresponding timeSlots, and the flow identification to recognize which packet is placed in which Track, sort out duplicates, etc. An example of an OCS and HMI is depicted in Figure 2.
TSCH を介したエンドツーエンド通信を考慮すると、6TiSCH デバイスは通常、ネットワーク内の他のデバイスとの間で帯域幅を要求しません。むしろ、ヒューマン/マシン インターフェイス (HMI) を通じて呼び出されるオペレーション コントロール システム (OCS) が、トラフィック仕様 (特に、遅延、信頼性、およびエンド ノードの点で) を PCE に提供します。これにより、PCE はエンド ノード間のトラックを計算し、トラック内のすべてのホップを、特定のパケットのホップごとの動作を記述するフローごとの状態、対応するタイムスロット、およびどのパケットがどのトラックに配置されているかを認識し、重複を分類するなどのフロー ID でプロビジョニングします。OCS と HMI の例を図 2 に示します。
For a static configuration that serves a certain purpose for a long period of time, it is expected that a node will be provisioned in one shot with a full schedule, which incorporates the aggregation of its behavior for multiple Tracks. The 6TiSCH architecture expects that the programming of the schedule is done over the Constrained Application Protocol (CoAP) as discussed in [CoAP-6TiSCH].
長期間にわたって特定の目的を果たす静的構成の場合、複数のトラックの動作の集約を組み込んだ完全なスケジュールでノードが 1 回でプロビジョニングされることが期待されます。6TiSCH アーキテクチャは、[CoAP-6TiSCH] で説明されているように、スケジュールのプログラミングが Constrained Application Protocol (CoAP) 上で行われることを想定しています。
However, a Hybrid mode may be required as well, whereby a single Track is added, modified, or removed (for instance, if it appears that a Track does not perform as expected). For that case, the expectation is that a protocol that flows along a Track, in a fashion similar to classical Traffic Engineering (TE) [CCAMP], may be used to update the state in the devices. In general, that flow was not designed, and it is expected that DetNet will determine the appropriate end-to-end protocols to be used in that case.
ただし、単一のトラックを追加、変更、または削除するハイブリッド モードも必要な場合があります (たとえば、トラックが期待どおりに動作しないように見える場合)。その場合、従来のトラフィック エンジニアリング (TE) [CCAMP] と同様の方法で、トラックに沿って流れるプロトコルを使用してデバイスの状態を更新できることが期待されます。一般に、そのフローは設計されたものではなく、その場合に使用される適切なエンドツーエンド プロトコルを DetNet が決定することが期待されます。
Operational Control System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \
Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device--
Figure 2: Architectural Layers
図 2: アーキテクチャ層
Section 4.7.1 of [RFC9030] describes the packet tagging and marking that is expected in 6TiSCH networks.
[RFC9030] のセクション 4.7.1 では、6TiSCH ネットワークで期待されるパケットのタグ付けとマーキングについて説明しています。
Packets that are routed by a PCE along a Track are tagged to uniquely identify the Track and associated transmit bundle of timeSlots.
トラックに沿って PCE によってルーティングされるパケットには、トラックおよび関連するタイムスロットの送信バンドルを一意に識別するためにタグが付けられます。
As a result, the tagging that is used for a DetNet flow outside the 6TiSCH Low-Power and Lossy Network (LLN) must be swapped into 6TiSCH formats and back as the packet enters and then leaves the 6TiSCH network.
その結果、6TiSCH 低電力損失ネットワーク (LLN) の外側の DetNet フローに使用されるタグ付けは、パケットが 6TiSCH ネットワークに出入りするときに、6TiSCH 形式に交換して戻す必要があります。
The 6TiSCH architecture [RFC9030] leverages PREOF over several alternate paths in a network to provide redundancy and parallel transmissions to bound the end-to-end delay. Considering the scenario shown in Figure 3, many different paths are possible for S to reach R. A simple way to benefit from this topology could be to use the two independent paths via nodes A, C, E and via B, D, F, but more complex paths are possible as well.
6TiSCH アーキテクチャ [RFC9030] は、ネットワーク内の複数の代替パス上で PREOF を利用して、エンドツーエンドの遅延を制限する冗長性と並列送信を提供します。図 3 に示すシナリオを考慮すると、S から R に到達するまでにさまざまなパスが可能です。このトポロジのメリットを享受する簡単な方法は、ノード A、C、E 経由と B、D、F 経由の 2 つの独立したパスを使用することですが、より複雑なパスも可能です。
(A) (C) (E)
source (S) (R) (destination)
(B) (D) (F)
Figure 3: A Typical Ladder Shape with Two Parallel Paths Toward the Destination
図 3: 目的地に向かう 2 つの平行なパスを持つ典型的なはしごの形状
By employing a packet replication function, each node forwards a copy of each data packet over two different branches. For instance, in Figure 4, the source node S transmits the data packet to nodes A and B, in two different timeSlots within the same TSCH slotframe. In the figure below, S transmits the same data packet twice: once to its Destination Parent (DP) (A) and once to its Alternate Parent (AP) (B).
パケット複製機能を使用することにより、各ノードは 2 つの異なるブランチを介して各データ パケットのコピーを転送します。たとえば、図 4 では、ソース ノード S は、同じ TSCH スロットフレーム内の 2 つの異なるタイムスロットでデータ パケットをノード A および B に送信します。以下の図では、S は同じデータ パケットを 2 回送信します。1 回目は宛先親 (DP) に送信され (A)、もう 1 回は代替親 (AP) に送信されます (B)。
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (destination)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 4: Packet Replication
図 4: パケットのレプリケーション
By employing a packet elimination function once it receives the first copy of a data packet, a node discards the subsequent copies. Because the first copy that reaches a node is the one that matters, it is the only copy that will be forwarded upward.
ノードは、データ パケットの最初のコピーを受信すると、パケット削除機能を使用して、後続のコピーを破棄します。ノードに到達する最初のコピーが重要であるため、上向きに転送される唯一のコピーになります。
Considering that the wireless medium is broadcast by nature, any neighbor of a transmitter may overhear a transmission. By employing the promiscuous overhearing function, nodes will have multiple opportunities to receive a given data packet. For instance, in Figure 4, when the source node S transmits the data packet to node A, node B may overhear the transmission.
無線メディアは本質的にブロードキャストであることを考慮すると、送信機の近隣の誰かが送信を傍受する可能性があります。無差別聴取機能を採用することにより、ノードは特定のデータ パケットを受信する機会を複数得ることができます。たとえば、図 4 では、ソース ノード S がデータ パケットをノード A に送信すると、ノード B がその送信を傍受する可能性があります。
6TiSCH expects elimination and replication of packets along a complex Track but has no position about how the sequence numbers would be tagged in the packet.
6TiSCH は、複雑なトラックに沿ったパケットの削除と複製を期待していますが、パケット内でシーケンス番号がどのようにタグ付けされるかについては見解を持っていません。
As it goes, 6TiSCH expects that timeSlots corresponding to copies of the same packet along a Track are correlated by configuration, so processing the sequence numbers is not needed.
6TiSCH は、トラックに沿った同じパケットのコピーに対応するタイムスロットが設定によって相関していることを期待しているため、シーケンス番号の処理は必要ありません。
The semantics of the configuration must enable correlated timeSlots to be grouped for transmit (and receive, respectively) with 'OR' relations, and then an 'AND' relation must be configurable between groups. The semantics are such that if the transmit (and receive, respectively) operation succeeded in one timeSlot in an 'OR' group, then all the other timeSlots in the group are ignored. Now, if there are at least two groups, the 'AND' relation between the groups indicates that one operation must succeed in each of the groups. Further details can be found in the 6TiSCH architecture document [RFC9030].
設定のセマンティクスでは、相関するタイムスロットを「OR」関係で送信 (および受信) 用にグループ化できるようにする必要があり、グループ間で「AND」関係を設定できる必要があります。セマンティクスは、「OR」グループ内の 1 つのタイムスロットで送信 (および受信) 操作が成功した場合、グループ内の他のすべてのタイムスロットが無視されるようなものです。ここで、少なくとも 2 つのグループがある場合、グループ間の「AND」関係は、各グループで 1 つの操作が成功する必要があることを示します。詳細については、6TiSCH アーキテクチャ文書 [RFC9030] を参照してください。
6TiSCH nodes are usually IoT devices, characterized by a very limited amount of memory, just enough buffers to store one or a few IPv6 packets, and limited bandwidth between peers. As a result, a node will maintain only a small amount of peering information and will not be able to store many packets waiting to be forwarded. Peers can be identified through MAC or IPv6 addresses.
6TiSCH ノードは通常、非常に限られた量のメモリ、1 つまたはいくつかの IPv6 パケットを保存するのに十分なバッファ、およびピア間の制限された帯域幅を特徴とする IoT デバイスです。その結果、ノードは少量のピアリング情報のみを保持し、転送を待つ多くのパケットを保存できなくなります。ピアは MAC アドレスまたは IPv6 アドレスを通じて識別できます。
Neighbors can be discovered over the radio using mechanisms such as enhanced beacons, but although the neighbor information is available in the 6TiSCH interface data model, 6TiSCH does not describe a protocol to proactively push the neighborhood information to a PCE. This protocol should be described and should operate over CoAP. The protocol should be able to carry multiple metrics, in particular, the same metrics that are used for RPL operations [RFC6551].
拡張ビーコンなどのメカニズムを使用して、近隣ノードを無線経由で検出できます。ただし、近隣情報は 6TiSCH インターフェイス データ モデルで利用できますが、6TiSCH は近隣情報を PCE に積極的にプッシュするプロトコルについては記述していません。このプロトコルは記述され、CoAP 上で動作する必要があります。プロトコルは複数のメトリック、特に RPL 操作 [RFC6551] に使用されるのと同じメトリックを伝送できる必要があります。
The energy that the device consumes in sleep, transmit, and receive modes can be evaluated and reported, and so can the amount of energy that is stored in the device and the power that can be scavenged from the environment. The PCE should be able to compute Tracks that will implement policies on how the energy is consumed, for instance, policies that balance between nodes and ensure that the spent energy does not exceed the scavenged energy over a period of time.
デバイスがスリープ、送信、受信モードで消費するエネルギーを評価してレポートすることができ、デバイスに保存されているエネルギー量や環境から回収できる電力も同様に評価および報告できます。PCE は、エネルギーがどのように消費されるかに関するポリシー、たとえばノード間のバランスをとり、一定期間にわたって消費されたエネルギーが回収されたエネルギーを超えないようにするポリシーなどを実装するトラックを計算できなければなりません。
6TiSCH supports a mixed model of centralized routes and distributed routes. Centralized routes can, for example, be computed by an entity such as a PCE [PCE]. Distributed routes are computed by RPL [RFC6550].
6TiSCH は、集中型ルートと分散型ルートの混合モデルをサポートします。たとえば、集中ルートは、PCE [PCE] などのエンティティによって計算できます。分散ルートは RPL [RFC6550] によって計算されます。
Both methods may inject routes in the routing tables of the 6TiSCH routers. In either case, each route is associated with a 6TiSCH topology that can be a RPL Instance topology or a Track. The 6TiSCH topology is indexed by an Instance ID, in a format that reuses the RPLInstanceID as defined in RPL.
どちらの方法でも、6TiSCH ルーターのルーティング テーブルにルートを挿入できます。いずれの場合も、各ルートは、RPL インスタンス トポロジまたはトラックとなる 6TiSCH トポロジに関連付けられます。6TiSCH トポロジは、RPL で定義されている RPLInstanceID を再利用する形式で、インスタンス ID によってインデックス付けされます。
Both RPL and PCE rely on shared sources such as policies to define Global and Local RPLInstanceIDs that can be used by either method. It is possible for centralized and distributed routing to share the same topology. Generally, they will operate in different slotframes, and centralized routes will be used for scheduled traffic and will have precedence over distributed routes in case of conflict between the slotframes.
RPL と PCE は両方とも、ポリシーなどの共有ソースに依存して、どちらの方法でも使用できるグローバル RPLInstanceID とローカル RPLInstanceID を定義します。集中ルーティングと分散ルーティングが同じトポロジを共有することが可能です。一般に、これらは異なるスロットフレームで動作し、集中ルートはスケジュールされたトラフィックに使用され、スロットフレーム間で競合が発生した場合には分散ルートよりも優先されます。
IEEE 802.15.4 TSCH avoids contention on the medium by formatting time and frequencies in cells of transmission of equal duration. In order to describe that formatting of time and frequencies, the 6TiSCH architecture defines a global concept that is called a Channel Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of cells with a height equal to the number of available channels (indexed by channelOffsets) and a width (in timeSlots) that is the period of the network scheduling operation (indexed by slotOffsets) for that CDU matrix.
IEEE 802.15.4 TSCH は、同じ持続時間の送信セル内の時間と周波数をフォーマットすることで、メディア上の競合を回避します。時間と周波数のフォーマットを記述するために、6TiSCH アーキテクチャは、チャネル分布および使用法 (CDU) マトリックスと呼ばれるグローバル概念を定義します。CDU マトリックスは、高さが利用可能なチャネルの数 (channelOffsets によってインデックス付けされる) と等しく、幅 (timeSlots 単位) がその CDU マトリックスのネットワーク スケジューリング操作 (slotOffsets によってインデックス付けされる) の期間であるセルのマトリックスです。
The CDU matrix is used by the PCE as the map of all the channel utilization. This organization depends on the time in the future. The frequency used by a cell in the matrix rotates in a pseudorandom fashion, from an initial position at an epoch time, as the CDU matrix iterates over and over.
CDU マトリックスは、PCE によってすべてのチャネル使用率のマップとして使用されます。この組織は将来の時代に依存します。CDU マトリックスが何度も反復されると、マトリックス内のセルによって使用される周波数は、エポック タイムの初期位置から擬似ランダムに回転します。
The size of a cell is a timeSlot duration, and values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to accommodate for the transmission of a frame and an acknowledgement, including the security validation on the receive side, which may take up to a few milliseconds on some device architectures. The matrix represents the overall utilization of the spectrum over time by a scheduled network operation.
セルのサイズはタイムスロット期間であり、802.15.4 TSCH では、受信側でのセキュリティ検証を含むフレームと確認応答の送信に対応するために 10 ～ 15 ミリ秒の値が一般的です。これには、一部のデバイス アーキテクチャでは最大で数ミリ秒かかる場合があります。マトリックスは、スケジュールされたネットワーク操作によるスペクトルの全体的な使用率を時間の経過とともに表します。
A CDU matrix is computed by the PCE, but unallocated timeSlots may be used opportunistically by the nodes for classical best-effort IP traffic. The PCE has precedence in the allocation in case of a conflict. Multiple schedules may coexist, in which case the schedule adds a dimension to the matrix, and the dimensions are ordered by priority.
CDU マトリックスは PCE によって計算されますが、割り当てられていないタイムスロットは、従来のベストエフォート IP トラフィックのノードによって便宜的に使用される可能性があります。競合が発生した場合、PCE が優先して割り当てられます。複数のスケジュールが共存する場合があります。その場合、スケジュールはマトリックスに次元を追加し、次元は優先順位に従って並べられます。
A slotframe is the base object that a PCE needs to manipulate to program a schedule into one device. The slotframe is a device's perspective of a transmission schedule; there can be more than one with different priorities so in case of a contention the highest priority applies. In other words, a slotframe is the projection of a schedule from the CDU matrix onto one device. Elaboration on that concept can be found in Section 4.3.5 of [RFC9030], and Figures 17 and 18 of [RFC9030] illustrate that projection.
スロットフレームは、スケジュールを 1 つのデバイスにプログラムするために PCE が操作する必要がある基本オブジェクトです。スロットフレームは、デバイスの送信スケジュールの観点です。異なる優先順位を持つものが複数存在する可能性があるため、競合が発生した場合には最も高い優先順位が適用されます。言い換えれば、スロットフレームは、CDU マトリックスから 1 つのデバイスへのスケジュールの投影です。この概念の詳細は [RFC9030] のセクション 4.3.5 にあり、[RFC9030] の図 17 と図 18 はその予測を示しています。
5G technology enables deterministic communication. Based on the centralized admission control and the scheduling of the wireless resources, licensed or unlicensed, Quality of Service (QoS) such as latency and reliability can be guaranteed. 5G contains several features to achieve ultra-reliable and low-latency performance (e.g., support for different OFDM numerologies and slot durations), as well as fast processing capabilities and redundancy techniques that lead to achievable latency numbers of below 1 ms with 99.999% or higher confidence.
5G テクノロジーにより、確定的な通信が可能になります。集中型のアドミッション制御と無線リソースのスケジューリングに基づいて、ライセンスの有無にかかわらず、待ち時間や信頼性などのサービス品質 (QoS) を保証できます。5G には、非常に信頼性の高い低遅延パフォーマンスを実現するためのいくつかの機能 (さまざまな OFDM ヌメロロジーやスロット期間のサポートなど) に加え、99.999% 以上の信頼性で 1 ミリ秒未満の遅延数を達成できる高速処理機能と冗長技術が含まれています。
5G also includes features to support industrial IoT use cases, e.g., via the integration of 5G with TSN. This includes 5G capabilities for each TSN component, latency, resource management, time synchronization, and reliability. Furthermore, 5G support for TSN can be leveraged when 5G is used as the subnet technology for DetNet, in combination with or instead of TSN, which is the primary subnet for DetNet. In addition, the support for integration with TSN reliability was added to 5G by making DetNet reliability also applicable, due to the commonalities between TSN and DetNet reliability. Moreover, providing IP service is native to 5G, and 3GPP Release 18 adds direct support for DetNet to 5G.
5G には、5G と TSN の統合など、産業用 IoT のユースケースをサポートする機能も含まれています。これには、各 TSN コンポーネントの 5G 機能、遅延、リソース管理、時刻同期、信頼性が含まれます。Furthermore, 5G support for TSN can be leveraged when 5G is used as the subnet technology for DetNet, in combination with or instead of TSN, which is the primary subnet for DetNet.さらに、TSN と DetNet の信頼性の共通点により、DetNet の信頼性も適用できるようにすることで、TSN 信頼性との統合のサポートが 5G に追加されました。さらに、IP サービスの提供は 5G にネイティブであり、3GPP リリース 18 では DetNet の直接サポートが 5G に追加されています。
Overall, 5G provides scheduled wireless segments with high reliability and availability. In addition, 5G includes capabilities for integration to IP networks. This makes 5G a suitable technology upon which to apply RAW.
全体として、5G は、スケジュールされた無線セグメントに高い信頼性と可用性を提供します。さらに、5G には IP ネットワークへの統合機能が含まれています。このため、5G は RAW を適用するのに適したテクノロジーになります。
The 3rd Generation Partnership Project (3GPP) incorporates many companies whose business is related to cellular network operation as well as network equipment and device manufacturing. All generations of 3GPP technologies provide scheduled wireless segments, primarily in licensed spectrum, which is beneficial for reliability and availability.
第 3 世代パートナーシップ プロジェクト (3GPP) には、セルラー ネットワークの運用、ネットワーク機器およびデバイスの製造に関連する事業を行う多くの企業が参加しています。すべての世代の 3GPP テクノロジーは、主にライセンスされたスペクトルでスケジュールされたワイヤレス セグメントを提供します。これは、信頼性と可用性の点で有益です。
In 2016, the 3GPP started to design New Radio (NR) technology belonging to the fifth generation (5G) of cellular networks. NR has been designed from the beginning to not only address enhanced Mobile Broadband (eMBB) services for consumer devices such as smart phones or tablets, but it is also tailored for future IoT communication and connected cyber-physical systems. In addition to eMBB, requirement categories have been defined on Massive Machine-Type Communication (M-MTC) for a large number of connected devices/sensors and on Ultra-Reliable Low-Latency Communications (URLLC) for connected control systems and critical communication as illustrated in Figure 5. It is the URLLC capabilities that make 5G a great candidate for reliable low-latency communication. With these three cornerstones, NR is a complete solution supporting the connectivity needs of consumers, enterprises, and the public sector for both wide-area and local-area (e.g., indoor) deployments. A general overview of NR can be found in [TS38300].
2016 年、3GPP はセルラー ネットワークの第 5 世代 (5G) に属する新しい無線 (NR) テクノロジーの設計を開始しました。NR は、スマートフォンやタブレットなどの消費者向けデバイス向けの拡張モバイル ブロードバンド (eMBB) サービスに対応するだけでなく、将来の IoT 通信や接続されたサイバー物理システムにも対応できるように最初から設計されています。eMBB に加えて、要件カテゴリは、図 5 に示すように、接続された多数のデバイス/センサー用の大規模マシンタイプ通信 (M-MTC) と、接続された制御システムおよび重要な通信用の超信頼性低遅延通信 (URLLC) で定義されています。5G を信頼性の高い低遅延通信の優れた候補にするのは、URLLC 機能です。これら 3 つの基礎により、NR は消費者、企業、公共部門の広域展開とローカルエリア (屋内など) 展開の両方の接続ニーズをサポートする完全なソリューションです。NR の概要については、[TS38300] を参照してください。
enhanced
Mobile Broadband
^
/ \
/ \
/ \
/ \
/ 5G \
/ \
/ \
/ \
+-----------------+
Massive Ultra-Reliable
Machine-Type Low-Latency
Communication Communication
Figure 5: 5G Application Areas
図 5: 5G 応用分野
As a result of releasing the first NR specification in 2018 (Release 15), it has been proven by many companies that NR is a URLLC-capable technology and can deliver data packets at 10^-5 packet error rate within a 1 ms latency budget [TR37910]. Those evaluations were consolidated and forwarded to ITU to be included in the work on [IMT2020].
2018 年に最初の NR 仕様 (リリース 15) をリリースした結果、NR が URLLC 対応テクノロジーであり、1 ミリ秒の遅延バジェット内で 10^-5 のパケット エラー レートでデータ パケットを配信できることが多くの企業によって証明されました [TR37910]。これらの評価は統合されて ITU に転送され、[IMT2020] の作業に組み込まれました。
In order to understand communication requirements for automation in vertical domains, 3GPP studied different use cases [TR22804] and released a technical specification with reliability, availability, and latency demands for a variety of applications [TS22104].
垂直ドメインにおける自動化の通信要件を理解するために、3GPP はさまざまなユースケースを研究し [TR22804]、さまざまなアプリケーションの信頼性、可用性、遅延の要件を記載した技術仕様をリリースしました [TS22104]。
As an evolution of NR, multiple studies that focus on radio aspects have been conducted in scope of 3GPP Release 16, including the following two:
NR の進化として、無線の側面に焦点を当てた複数の研究が 3GPP リリース 16 の範囲内で実施されており、その中には次の 2 つが含まれます。
1. "Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)" [TR38824]
1. 「NR 超高信頼性低遅延ケース (URLLC) の物理層拡張に関する研究」 [TR38824]
2. "Study on NR industrial Internet of Things (IoT)" [TR38825]
2. 「NR 産業用モノのインターネット (IoT) に関する研究」 [TR38825]
As a result of these studies, further enhancements to NR have been standardized in 3GPP Release 16 and are available in [TS38300] and continued in 3GPP Release 17 standardization (according to [RP210854]).
これらの研究の結果、NR のさらなる機能強化が 3GPP リリース 16 で標準化され、[TS38300] で利用可能になり、3GPP リリース 17 標準化でも継続されます ([RP210854] による)。
In addition, several enhancements have been made on the system architecture level, which are reflected in "System architecture for the 5G System (5GS)" [TS23501]. These enhancements include multiple features in support of Time-Sensitive Communications (TSC) by Release 16 and Release 17. Further improvements, such as support for DetNet [TR2370046], are provided in Release 18.
さらに、システム アーキテクチャ レベルでいくつかの機能強化が行われ、「5G システム (5GS) のシステム アーキテクチャ」[TS23501] に反映されています。これらの機能強化には、リリース 16 およびリリース 17 による時間依存通信 (TSC) をサポートする複数の機能が含まれています。リリース 18 では、DetNet [TR2370046] のサポートなどのさらなる改善が提供されます。
The adoption and the use of 5G is facilitated by multiple organizations. For instance, the 5G Alliance for Connected Industries and Automation (5G-ACIA) brings together widely varying 5G stakeholders including Information and Communication Technology (ICT) players and Operational Technology (OT) companies (e.g., industrial automation enterprises, machine builders, and end users). Another example is the 5G Automotive Association (5GAA), which bridges ICT and automotive technology companies to develop end-to-end solutions for future mobility and transportation services.
5G の導入と使用は、複数の組織によって促進されています。たとえば、コネクテッド インダストリーズとオートメーションのための 5G アライアンス (5G-ACIA) には、情報通信技術 (ICT) プレーヤーや運用技術 (OT) 企業 (産業オートメーション企業、機械製造業者、エンド ユーザーなど) を含む、多種多様な 5G 関係者が集まります。もう 1 つの例は、5G Automotive Association (5GAA) です。5G Automotive Association (5GAA) は、ICT 企業と自動車技術企業を橋渡しして、将来のモビリティおよび交通サービスのためのエンドツーエンドのソリューションを開発しています。
The 5G Radio Access Network (5G RAN) with its NR interface includes several features to achieve Quality of Service (QoS), such as a guaranteed low latency or tolerable packet error rates for selected data flows. Determinism is achieved by centralized admission control and scheduling of the wireless frequency resources, which are typically licensed frequency bands assigned to a network operator.
NR インターフェイスを備えた 5G 無線アクセス ネットワーク (5G RAN) には、保証された低遅延や選択されたデータ フローの許容可能なパケット エラー レートなど、サービス品質 (QoS) を達成するためのいくつかの機能が含まれています。決定性は、集中アドミッション コントロールと無線周波数リソースのスケジューリングによって実現されます。無線周波数リソースは通常、ネットワーク オペレータに割り当てられる認可された周波数帯域です。
NR enables short transmission slots in a radio subframe, which benefits low-latency applications. NR also introduces mini-slots, where prioritized transmissions can be started without waiting for slot boundaries, further reducing latency. As part of giving priority and faster radio access to URLLC traffic, NR introduces preemption, where URLLC data transmission can preempt ongoing non-URLLC transmissions. Additionally, NR applies very fast processing, enabling retransmissions even within short latency bounds.
NR により、無線サブフレーム内の短い送信スロットが可能になり、低遅延アプリケーションにメリットをもたらします。NR ではミニスロットも導入されており、スロット境界を待たずに優先順位付きの送信を開始できるため、待ち時間がさらに短縮されます。URLLC トラフィックへの優先的かつ高速な無線アクセスの一環として、NR はプリエンプションを導入しています。これにより、URLLC データ送信が進行中の非 URLLC 送信をプリエンプトできるようになります。さらに、NR は非常に高速な処理を適用するため、短い待ち時間の範囲内でも再送信が可能になります。
NR defines extra-robust transmission modes for increased reliability for both data and control radio channels. Reliability is further improved by various techniques, such as multi-antenna transmission, the use of multiple frequency carriers in parallel, and packet duplication over independent radio links. NR also provides full mobility support, which is an important reliability aspect not only for devices that are moving, but also for devices located in a changing environment.
NR は、データ チャネルと制御無線チャネルの両方の信頼性を高めるための非常に堅牢な送信モードを定義します。信頼性は、マルチアンテナ送信、複数の周波数搬送波の並列使用、独立した無線リンクでのパケット複製などのさまざまな技術によってさらに向上します。NR は完全なモビリティ サポートも提供します。これは、移動しているデバイスだけでなく、変化する環境にあるデバイスにとっても重要な信頼性の側面です。
Network slicing is seen as one of the key features for 5G, allowing vertical industries to take advantage of 5G networks and services. Network slicing is about transforming a Public Land Mobile Network (PLMN) from a single network to a network where logical partitions are created, with appropriate network isolation, resources, optimized topology, and specific configurations to serve various service requirements. An operator can configure and manage the mobile network to support various types of services enabled by 5G (e.g., eMBB and URLLC), depending on the different needs of customers.
ネットワーク スライシングは 5G の重要な機能の 1 つとみなされており、垂直産業が 5G ネットワークとサービスを活用できるようになります。ネットワーク スライシングとは、パブリック ランド モバイル ネットワーク (PLMN) を単一のネットワークから、適切なネットワーク分離、リソース、最適化されたトポロジ、およびさまざまなサービス要件を満たす特定の構成を備えた論理パーティションが作成されるネットワークに変換することです。通信事業者は、顧客のさまざまなニーズに応じて、5G によって実現されるさまざまなタイプのサービス (eMBB や URLLC など) をサポートするようにモバイル ネットワークを構成および管理できます。
Exposure of capabilities of 5G systems to the network or applications outside the 3GPP domain have been added to Release 16 [TS23501]. Applications can access 5G capabilities like communication service monitoring and network maintenance via exposure interfaces.
3GPP ドメイン外のネットワークまたはアプリケーションへの 5G システムの機能の公開がリリース 16 [TS23501] に追加されました。アプリケーションは、エクスポージャー インターフェイスを介して、通信サービスの監視やネットワーク メンテナンスなどの 5G 機能にアクセスできます。
For several generations of mobile networks, 3GPP has considered how the communication system should work on a global scale with billions of users, taking into account resilience aspects, privacy regulation, protection of data, encryption, access and core network security, as well as interconnect. Security requirements evolve as demands on trustworthiness increase. For example, this has led to the introduction of enhanced privacy protection features in 5G. 5G also employs strong security algorithms, encryption of traffic, protection of signaling, and protection of interfaces.
3GPP は、数世代のモバイル ネットワークを対象に、復元力の側面、プライバシー規制、データの保護、暗号化、アクセスとコア ネットワークのセキュリティ、相互接続を考慮して、通信システムが数十億のユーザーに対して地球規模でどのように機能するかを検討してきました。信頼性への要求が高まるにつれて、セキュリティ要件も進化します。たとえば、これにより、5G では強化されたプライバシー保護機能が導入されます。5G では、強力なセキュリティ アルゴリズム、トラフィックの暗号化、シグナリングの保護、インターフェイスの保護も採用されています。
One particular strength of mobile networks is the authentication, based on well-proven algorithms and tightly coupled with a global identity management infrastructure. Since 3G, there is also mutual authentication, allowing the network to authenticate the device and the device to authenticate the network. Another strength is secure solutions for storage and distribution of keys, fulfilling regulatory requirements and allowing international roaming. When connecting to 5G, the user meets the entire communication system, where security is the result of standardization, product security, deployment, operations, and management as well as incident-handling capabilities. The mobile networks approach the entirety in a rather coordinated fashion, which is beneficial for security.
モバイル ネットワークの特別な強みの 1 つは、実証済みのアルゴリズムに基づき、グローバルな ID 管理インフラストラクチャと密接に連携した認証です。3G 以降は相互認証も行われ、ネットワークがデバイスを認証し、デバイスがネットワークを認証することができます。もう 1 つの強みは、キーの保管と配布のための安全なソリューションであり、規制要件を満たし、国際ローミングを可能にします。5G に接続すると、ユーザーは通信システム全体に対応することになります。ここでのセキュリティは、標準化、製品セキュリティ、展開、運用、管理、およびインシデント処理能力の結果です。モバイル ネットワークは、かなり調整された方法で全体にアプローチするため、セキュリティにとって有益です。
The 5G system allows deployment in a vast spectrum range, addressing use cases in both wide-area and local-area networks. Furthermore, 5G can be configured for public and non-public access.
5G システムは広大なスペクトル範囲での展開を可能にし、ワイドエリア ネットワークとローカルエリア ネットワークの両方のユースケースに対応します。さらに、5G はパブリック アクセスおよび非パブリック アクセス用に構成できます。
When it comes to spectrum, NR allows combining the merits of many frequency bands, such as the high bandwidths in millimeter waves (mmWaves) for extreme capacity locally and the broad coverage when using mid- and low-frequency bands to address wide-area scenarios. URLLC is achievable in all these bands. Spectrum can be either licensed, which means that the license holder is the only authorized user of that spectrum range, or unlicensed, which means that anyone who wants to use the spectrum can do so.
スペクトルに関しては、NR を使用すると、ローカルで非常に大きな容量を実現するミリ波 (mmWave) の高帯域幅や、広域シナリオに対処するために中低周波数帯域を使用する場合の広いカバレッジなど、多くの周波数帯域の利点を組み合わせることができます。URLLC はこれらすべての帯域で実現可能です。スペクトルは、ライセンス所有者がそのスペクトル範囲の唯一の許可されたユーザーであることを意味するライセンス付きか、またはスペクトルを使用したい人は誰でも使用できることを意味するライセンスなしのいずれかです。
A prerequisite for critical communication is performance predictability, which can be achieved by full control of access to the spectrum, which 5G provides. Licensed spectrum guarantees control over spectrum usage by the system, making it a preferable option for critical communication. However, unlicensed spectrum can provide an additional resource for scaling non-critical communications. While NR was initially developed for usage of licensed spectrum, the functionality to also access unlicensed spectrum was introduced in 3GPP Release 16. Moreover, URLLC features are enhanced in Release 17 [RP210854] to be better applicable to unlicensed spectrum.
重要な通信の前提条件はパフォーマンスの予測可能性です。これは、5G が提供するスペクトルへのアクセスを完全に制御することで実現できます。ライセンスされたスペクトルは、システムによるスペクトル使用の制御を保証するため、重要な通信には望ましいオプションとなります。ただし、ライセンスのないスペクトルは、重要ではない通信を拡張するための追加リソースを提供できます。NR は当初、ライセンス付きスペクトルの使用を目的として開発されましたが、ライセンスなしスペクトルにもアクセスする機能が 3GPP リリース 16 で導入されました。さらに、URLLC 機能はリリース 17 [RP210854] で強化され、ライセンスなしスペクトルへの適用性が向上しました。
Licensed spectrum dedicated to mobile communications has been allocated to mobile service providers, i.e., issued as longer-term licenses by national administrations around the world. These licenses have often been associated with coverage requirements and issued across whole countries or large regions. Besides this, configured as a non-public network (NPN) deployment, 5G can also provide network services to a non-operator defined organization and its premises such as a factory deployment. With this isolation, QoS requirements as well as security requirements can be achieved. An integration with a public network, if required, is also possible. The non-public (local) network can thus be interconnected with a public network, allowing devices to roam between the networks.
モバイル通信専用の認可された周波数帯域は、モバイル サービス プロバイダーに割り当てられています。つまり、世界中の国家行政によって長期ライセンスとして発行されています。これらのライセンスは多くの場合、適用範囲要件に関連付けられており、国全体または大規模な地域にわたって発行されます。これに加えて、非公衆ネットワーク (NPN) 展開として構成された 5G は、事業者が定義していない組織や工場展開などのその施設にネットワーク サービスを提供することもできます。この分離により、セキュリティ要件だけでなく QoS 要件も達成できます。必要に応じて、パブリック ネットワークとの統合も可能です。したがって、非パブリック (ローカル) ネットワークをパブリック ネットワークと相互接続することができ、デバイスがネットワーク間でローミングできるようになります。
In an alternative model, some countries are now in the process of allocating parts of the 5G spectrum for local use to industries. These non-service providers then have the choice to apply for a local license themselves and operate their own network or to cooperate with a public network operator or service provider.
代替モデルとして、一部の国は現在、5G 周波数帯域の一部を地域での使用のために産業に割り当てる手続きを進めています。これらの非サービス プロバイダーは、ローカル ライセンスを自ら申請して独自のネットワークを運用するか、公衆ネットワーク オペレーターやサービス プロバイダーと協力するかを選択できます。
The 5G system [TS23501] consists of the User Equipment (UE) at the terminal side, the Radio Access Network (RAN) with the gNodeB (gNB) as radio base station node, and the Core Network (CN), which is connected to the external Data Network (DN). The CN is based on a service-based architecture with the following central functions: Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF) as illustrated in Figure 6. (Note that this document only explains key functions; however, Figure 6 provides a more detailed view, and [SYSTOVER5G] summarizes the functions and provides the full definitions of the acronyms used in the figure.)
5Gシステム【TS23501】は、端末側のUser Equipment（UE）、gNodeB（gNB）を無線基地局ノードとするRadio Access Network（RAN）、外部のData Network（DN）に接続されるCore Network（CN）で構成されます。CN は、図 6 に示すように、アクセスおよびモビリティ管理機能 (AMF)、セッション管理機能 (SMF)、およびユーザー プレーン機能 (UPF) という中心的な機能を備えたサービスベースのアーキテクチャに基づいています。(このドキュメントでは主要な機能のみを説明していることに注意してください。ただし、図 6 はより詳細な図を提供しており、[SYSTOVER5G] は機能を要約し、図で使用されている頭字語の完全な定義を提供しています)。
The gNB's main responsibility is radio resource management, including admission control and scheduling, mobility control, and radio measurement handling. The AMF handles the UE's connection status and security, while the SMF controls the UE's data sessions. The UPF handles the user plane traffic.
gNB の主な役割は、アドミッション制御とスケジューリング、モビリティ制御、無線測定処理などの無線リソース管理です。AMF は UE の接続ステータスとセキュリティを処理し、SMF は UE のデータ セッションを制御します。UPF はユーザー プレーンのトラフィックを処理します。
The SMF can instantiate various Packet Data Unit (PDU) sessions for the UE, each associated with a set of QoS flows, i.e., with different QoS profiles). Segregation of those sessions is also possible; for example, resource isolation in the RAN and CN can be defined (slicing).
SMF は、UE のさまざまなパケット データ ユニット (PDU) セッションをインスタンス化できます。各セッションは、一連の QoS フロー、つまり、異なる QoS プロファイルに関連付けられています。それらのセッションを分離することも可能です。たとえば、RAN と CN のリソース分離を定義できます (スライシング)。
+----+ +---+ +---+ +---+ +---+ +---+
|NSSF| |NEF| |NRF| |PCF| |UDM| |AF |
+--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+
| | | | | |
Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf|
| | | | | |
---+------+-+-----+-+------------+--+-----+-+---
| | | |
Nausf| Nausf| Nsmf| |
| | | |
+--+-+ +-+-+ +-+-+ +-+-+
|AUSF| |AMF| |SMF| |SCP|
+----+ +++-+ +-+-+ +---+
/ | |
/ | |
/ | |
N1 N2 N4
/ | |
/ | |
/ | |
+--+-+ +--+--+ +--+---+ +----+
| UE +---+(R)AN+--N3--+ UPF +--N6--+ DN |
+----+ +-----+ ++----++ +----+
| |
+-N9-+
Figure 6: 5G System Architecture
図 6: 5G システム アーキテクチャ
To allow UE mobility across cells/gNBs, handover mechanisms are supported in NR. For an established connection (i.e., connected mode mobility), a gNB can configure a UE to report measurements of received signal strength and quality of its own and neighboring cells, periodically or based on events. Based on these measurement reports, the gNB decides to hand over a UE to another target cell/ gNB. Before triggering the handover, it is handshaked with the target gNB based on network signaling. A handover command is then sent to the UE, and the UE switches its connection to the target cell/gNB. The Packet Data Convergence Protocol (PDCP) of the UE can be configured to avoid data loss in this procedure, i.e., to handle retransmissions if needed. Data forwarding is possible between source and target gNB as well. To improve the mobility performance further (i.e., to avoid connection failures due to too-late handovers), the mechanism of conditional handover is introduced in Release 16 specifications. Therein, a conditional handover command, defining a triggering point, can be sent to the UE before the UE enters a handover situation. A further improvement that has been introduced in Release 16 is the Dual Active Protocol Stack (DAPS), where the UE maintains the connection to the source cell while connecting to the target cell. This way, potential interruptions in packet delivery can be avoided entirely.
セル/gNB 間での UE モビリティを可能にするために、ハンドオーバー メカニズムが NR でサポートされています。確立された接続（つまり、コネクテッド モード モビリティ）の場合、gNB は、定期的に、またはイベントに基づいて、自身および隣接セルの受信信号強度と品質の測定値を報告するように UE を設定できます。これらの測定レポートに基づいて、gNB は UE を別のターゲット セル/gNB にハンドオーバーすることを決定します。ハンドオーバーをトリガーする前に、ネットワーク シグナリングに基づいてターゲット gNB とハンドシェイクされます。その後、ハンドオーバー コマンドが UE に送信され、UE は接続をターゲット セル/gNB に切り替えます。UE のパケット データ コンバージェンス プロトコル (PDCP) は、この手順でのデータ損失を回避するように、つまり、必要に応じて再送信を処理するように構成できます。ソース gNB とターゲット gNB の間でもデータ転送が可能です。モビリティ パフォーマンスをさらに向上させるため (つまり、遅すぎるハンドオーバーによる接続障害を回避するため)、条件付きハンドオーバーのメカニズムがリリース 16 仕様に導入されました。そこでは、ＵＥがハンドオーバ状況に入る前に、トリガポイントを定義する条件付きハンドオーバコマンドをＵＥに送信することができる。リリース 16 で導入されたさらなる改良点は、デュアル アクティブ プロトコル スタック (DAPS) です。これにより、UE はターゲット セルに接続しながらソース セルへの接続を維持します。このようにして、パケット配信の潜在的な中断を完全に回避できます。
The protocol architecture for NR consists of the Layer 1 Physical (PHY) layer and, as part of Layer 2, the sublayers of Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaption Protocol (SDAP).
NR のプロトコル アーキテクチャは、レイヤー 1 物理 (PHY) レイヤーと、レイヤー 2 の一部としてのメディア アクセス コントロール (MAC)、無線リンク コントロール (RLC)、パケット データ コンバージェンス プロトコル (PDCP)、およびサービス データ アダプション プロトコル (SDAP) のサブレイヤーで構成されます。
The PHY layer handles actions related to signal processing, such as encoding/decoding of data and control bits, modulation, antenna precoding, and mapping.
PHY 層は、データと制御ビットのエンコード/デコード、変調、アンテナ プリコーディング、マッピングなどの信号処理に関連するアクションを処理します。
The MAC sublayer handles multiplexing and priority handling of logical channels (associated with QoS flows) to transport blocks for PHY transmission, as well as scheduling information reporting and error correction through Hybrid Automated Repeat Request (HARQ).
MAC サブレイヤは、PHY 送信用のブロックをトランスポートするための論理チャネル (QoS フローに関連付けられた) の多重化と優先処理を処理するだけでなく、ハイブリッド自動再送要求 (HARQ) を介したスケジューリング情報レポートとエラー修正も処理します。
The RLC sublayer handles sequence numbering of higher-layer packets, retransmissions through Automated Repeat Request (ARQ), if configured, as well as segmentation and reassembly and duplicate detection.
RLC サブレイヤは、上位レイヤ パケットのシーケンス番号付け、自動再送要求 (ARQ) (設定されている場合) による再送信、さらにセグメント化、再構成、重複検出を処理します。
The PDCP sublayer consists of functionalities for ciphering/ deciphering, integrity protection/verification, reordering and in-order delivery, and duplication and duplicate handling for higher-layer packets. This sublayer also acts as the anchor protocol to support handovers.
PDCP サブレイヤは、暗号化/解読、完全性保護/検証、並べ替えと順序どおりの配信、および上位層パケットの重複と重複処理の機能で構成されます。このサブレイヤーは、ハンドオーバーをサポートするアンカー プロトコルとしても機能します。
The SDAP sublayer provides services to map QoS flows, as established by the 5G core network, to data radio bearers (associated with logical channels), as used in the 5G RAN.
SDAP サブレイヤは、5G コア ネットワークによって確立された QoS フローを、5G RAN で使用されるデータ無線ベアラ (論理チャネルに関連付けられた) にマッピングするサービスを提供します。
Additionally, in RAN, the Radio Resource Control (RRC) protocol handles the access control and configuration signaling for the aforementioned protocol layers. RRC messages are considered Layer 3 and are thus also transmitted via those radio protocol layers.
さらに、RAN では、無線リソース制御 (RRC) プロトコルが、前述のプロトコル層のアクセス制御と構成シグナリングを処理します。RRC メッセージはレイヤ 3 とみなされ、したがってこれらの無線プロトコル レイヤ経由でも送信されます。
To provide low latency and high reliability for one transmission link (i.e., to transport data or control signaling of one radio bearer via one carrier), several features have been introduced on the user plane protocols for PHY and Layer 2, as explained below.
1 つの送信リンクに低レイテンシーと高い信頼性を提供する (つまり、1 つのキャリアを介して 1 つの無線ベアラーのデータを転送または制御する) ために、以下で説明するように、PHY およびレイヤー 2 のユーザー プレーン プロトコルにいくつかの機能が導入されています。
NR is designed with native support of antenna arrays utilizing benefits from beamforming, transmissions over multiple MIMO layers, and advanced receiver algorithms allowing effective interference cancellation. Those antenna techniques are the basis for high signal quality and the effectiveness of spectral usage. Spatial diversity with up to four MIMO layers in UL and up to eight MIMO layers in DL is supported. Together with spatial-domain multiplexing, antenna arrays can focus power in the desired direction to form beams. NR supports beam management mechanisms to find the best suitable beam for UE initially and when it is moving. In addition, gNBs can coordinate their respective downlink (DL) and uplink (UL) transmissions over the backhaul network, keeping interference reasonably low, and even make transmissions or receptions from multiple points (multi-TRP). Multi-TRP can be used for repetition of a data packet in time, in frequency, or over multiple MIMO layers, which can improve reliability even further.
NR は、ビームフォーミング、複数の MIMO レイヤーを介した送信、および効果的な干渉キャンセルを可能にする高度な受信機アルゴリズムの利点を利用して、アンテナ アレイをネイティブにサポートするように設計されています。これらのアンテナ技術は、高い信号品質とスペクトル利用の有効性の基礎となります。UL では最大 4 つの MIMO レイヤー、DL では最大 8 つの MIMO レイヤーによる空間ダイバーシティがサポートされます。空間領域多重化と組み合わせることで、アンテナ アレイは電力を目的の方向に集中させてビームを形成できます。NR は、初期時および移動時に UE に最適なビームを見つけるためのビーム管理メカニズムをサポートしています。さらに、gNB は、バックホール ネットワーク上でそれぞれのダウンリンク (DL) およびアップリンク (UL) 送信を調整して、干渉を適度に低く保ち、複数のポイントから送信または受信を行うこともできます (マルチ TRP)。マルチ TRP は、時間内、周波数内、または複数の MIMO レイヤーにわたるデータ パケットの繰り返しに使用でき、信頼性をさらに向上させることができます。
Any DL transmission to a UE starts from resource allocation signaling over the Physical Downlink Control Channel (PDCCH). If it is successfully received, the UE will know about the scheduled transmission and may receive data over the Physical Downlink Shared Channel (PDSCH). If retransmission is required according to the HARQ scheme, a signaling of negative acknowledgement (NACK) on the Physical Uplink Control Channel (PUCCH) is involved, and PDCCH together with PDSCH transmissions (possibly with additional redundancy bits) are transmitted and soft-combined with previously received bits. Otherwise, if no valid control signaling for scheduling data is received, nothing is transmitted on PUCCH (discontinuous transmission (DTX)), and upon detecting DTX, the base station will retransmit the initial data.
UE への DL 送信は、物理ダウンリンク制御チャネル (PDCCH) を介したリソース割り当てシグナリングから始まります。受信に成功すると、UE はスケジュールされた送信について知り、物理ダウンリンク共有チャネル (PDSCH) 経由でデータを受信できるようになります。HARQ 方式に従って再送信が必要な場合、物理アップリンク制御チャネル (PUCCH) 上の否定応答 (NACK) のシグナリングが含まれ、PDCCH が PDSCH 送信 (おそらく追加の冗長ビットを含む) とともに送信され、以前に受信したビットとソフト結合されます。それ以外の場合、データをスケジューリングするための有効な制御シグナリングが受信されない場合、PUCCH (不連続送信 (DTX)) では何も送信されず、DTX を検出すると、基地局は初期データを再送信します。
An UL transmission normally starts from a Scheduling Request (SR), a signaling message from the UE to the base station sent via PUCCH. Once the scheduler is informed about buffer data in the UE (e.g., by SR), the UE transmits a data packet on the Physical Uplink Shared Channel (PUSCH). Pre-scheduling, not relying on SR, is also possible (see Section 6.4.4).
UL 送信は通常、PUCCH を介して送信される UE から基地局へのシグナリング メッセージであるスケジューリング要求 (SR) から始まります。スケジューラがＵＥ内のバッファデータについて（例えば、ＳＲによって）通知されると、ＵＥは物理アップリンク共有チャネル（ＰＵＳＣＨ）上でデータパケットを送信する。SR に依存しない事前スケジューリングも可能です (セクション 6.4.4 を参照)。
Since transmission of data packets requires usage of control and data channels, there are several methods to maintain the needed reliability. NR uses Low Density Parity Check (LDPC) codes for data channels, polar codes for PDCCH, as well as orthogonal sequences and polar codes for PUCCH. For ultra-reliability of data channels, very robust (low-spectral efficiency) Modulation and Coding Scheme (MCS) tables are introduced containing very low (down to 1/20) LDPC code rates using Binary Phase-Shift Keying (BPSK) or Quadrature Phase-Shift Keying (QPSK). Also, PDCCH and PUCCH channels support multiple code rates including very low ones for the channel robustness.
データ パケットの送信には制御チャネルとデータ チャネルを使用する必要があるため、必要な信頼性を維持する方法がいくつかあります。NR は、データ チャネルに低密度パリティ チェック (LDPC) コード、PDCCH にポーラー コード、および PUCCH に直交シーケンスとポーラー コードを使用します。データ チャネルの信頼性を高めるために、2 相位相偏移キーイング (BPSK) または四相位相偏移キーイング (QPSK) を使用した非常に低い (1/20 までの) LDPC コード レートを含む、非常に堅牢な (スペクトル効率の低い) 変調符号化方式 (MCS) テーブルが導入されています。また、PDCCH および PUCCH チャネルは、チャネルの堅牢性のために非常に低いコード レートを含む複数のコード レートをサポートします。
A connected UE reports DL quality to gNB by sending Channel State Information (CSI) reports via PUCCH while UL quality is measured directly at gNB. For both UL and DL, gNB selects the desired MCS number and signals it to the UE by Downlink Control Information (DCI) via PDCCH channel. For URLLC services, the UE can assist the gNB by advising that MCS targeting a 10^-5 Block Error Rate (BLER) are used. Robust link adaptation algorithms can maintain the needed level of reliability, considering a given latency bound.
接続された UE は、PUCCH 経由でチャネル状態情報 (CSI) レポートを送信することで DL 品質を gNB に報告しますが、UL 品質は gNB で直接測定されます。UL と DL の両方で、gNB は必要な MCS 番号を選択し、PDCCH チャネルを介してダウンリンク制御情報 (DCI) によって UE に通知します。URLLC サービスの場合、UE は、10^-5 のブロック エラー レート (BLER) をターゲットとする MCS が使用されることをアドバイスすることで gNB を支援できます。堅牢なリンク適応アルゴリズムは、特定の遅延限界を考慮して、必要なレベルの信頼性を維持できます。
Low latency on the PHY layer is provided by short transmission duration, which is possible by using high Subcarrier Spacing (SCS) and the allocation of only one or a few Orthogonal Frequency Division Multiplexing (OFDM) symbols. For example, the shortest latency for the worst case is 0.23 ms in DL and 0.24 ms in UL (according to Section 5.7.1 in [TR37910]). Moreover, if the initial transmission has failed, HARQ feedback can quickly be provided and an HARQ retransmission scheduled.
PHY 層での低遅延は、短い送信期間によって実現されます。これは、高いサブキャリア間隔 (SCS) と 1 つまたは少数の直交周波数分割多重 (OFDM) シンボルのみの割り当てを使用することによって可能になります。たとえば、最悪の場合の最短遅延は DL で 0.23 ミリ秒、UL で 0.24 ミリ秒です ([TR37910] のセクション 5.7.1 による)。さらに、最初の送信が失敗した場合、HARQ フィードバックがすぐに提供され、HARQ 再送信がスケジュールされます。
Dynamic multiplexing of data associated with different services is highly desirable for efficient use of system resources and to maximize system capacity. Assignment of resources for eMBB is usually done with regular (longer) transmission slots, which can lead to blocking of low-latency services. To overcome the blocking, eMBB resources can be preempted and reassigned to URLLC services. In this way, spectrally efficient assignments for eMBB can be ensured while providing the flexibility required to ensure a bounded latency for URLLC services. In DL, the gNB can notify the eMBB UE about preemption after it has happened, while in UL there are two preemption mechanisms: special signaling to cancel eMBB transmission and URLLC dynamic power boost to suppress eMBB transmission.
システム リソースを効率的に使用し、システム容量を最大化するには、さまざまなサービスに関連付けられたデータを動的に多重化することが非常に望ましいです。eMBB へのリソースの割り当ては通常、通常の (長い) 送信スロットで行われるため、低遅延サービスのブロックにつながる可能性があります。ブロッキングを克服するために、eMBB リソースをプリエンプトして URLLC サービスに再割り当てできます。このようにして、URLLC サービスの制限された遅延を確保するために必要な柔軟性を提供しながら、eMBB に対するスペクトル効率の高い割り当てを確保できます。DL では、gNB はプリエンプションの発生後に eMBB UE に通知できますが、UL では、eMBB 送信をキャンセルする特別なシグナリングと、eMBB 送信を抑制する URLLC 動的パワー ブーストの 2 つのプリエンプション メカニズムがあります。
One integral part of the 5G system is the Quality of Service (QoS) framework [TS23501]. QoS flows are set up by the 5G system for certain IP or Ethernet packet flows, so that packets of each flow receive the same forwarding treatment (i.e., in scheduling and admission control). For example, QoS flows can be associated with different priority levels, packet delay budgets, and tolerable packet error rates. Since radio resources are centrally scheduled in NR, the admission control function can ensure that only QoS flows for which QoS targets can be reached are admitted.
5G システムに不可欠な部分の 1 つは、サービス品質 (QoS) フレームワーク [TS23501] です。QoS フローは、特定の IP またはイーサネット パケット フローに対して 5G システムによって設定されるため、各フローのパケットは同じ転送処理 (つまり、スケジューリングとアドミッション コントロールで) を受けます。たとえば、QoS フローは、さまざまな優先レベル、パケット遅延バジェット、および許容可能なパケット エラー率に関連付けることができます。無線リソースは NR で集中的にスケジュールされるため、アドミッション制御機能により、QoS 目標に到達できる QoS フローのみが許可されることが保証されます。
NR transmissions in both UL and DL are scheduled by the gNB [TS38300]. This ensures radio resource efficiency and fairness in resource usage of the users, and it enables differentiated treatment of the data flows of the users according to the QoS targets of the flows. Those QoS flows are handled as data radio bearers or logical channels in NR RAN scheduling.
UL と DL の両方での NR 送信は、gNB によってスケジュールされます [TS38300]。これにより、無線リソースの効率性とユーザーのリソース使用の公平性が確保され、フローの QoS 目標に応じてユーザーのデータ フローを差別化して処理できるようになります。これらの QoS フローは、NR RAN スケジューリングでデータ無線ベアラーまたは論理チャネルとして処理されます。
The gNB can dynamically assign DL and UL radio resources to users, indicating the resources as DL assignments or UL grants via control channel to the UE. Radio resources are defined as blocks of OFDM symbols in spectral domain and time domain. Different lengths are supported in time domain, (i.e., multiple slot or mini-slot lengths). Resources of multiple frequency carriers can be aggregated and jointly scheduled to the UE.
gNB は、DL および UL 無線リソースをユーザーに動的に割り当てることができ、制御チャネルを介してリソースを DL 割り当てまたは UL 許可として UE に示します。無線リソースは、スペクトル領域および時間領域の OFDM シンボルのブロックとして定義されます。時間領域ではさまざまな長さがサポートされます (つまり、複数のスロットまたはミニスロットの長さ)。複数の周波数キャリアのリソースを集約して、UE に対して共同でスケジュールすることができます。
Scheduling decisions are based, e.g., on channel quality measured on reference signals and reported by the UE (cf. periodical CSI reports for DL channel quality). The transmission reliability can be chosen in the scheduling algorithm, i.e., chosen by link adaptation where an appropriate transmission format (e.g., robustness of modulation and coding scheme, controlled UL power) is selected for the radio channel condition of the UE. Retransmissions, based on HARQ feedback, are also controlled by the scheduler. The feedback transmission in HARQ loop introduces delays, but there are methods to minimize it by using short transmission formats, sub-slot feedback reporting, and PUCCH carrier switching. If needed to avoid HARQ round-trip time delays, repeated transmissions can be also scheduled beforehand, to the cost of reduced spectral efficiency.
スケジューリングの決定は、例えば、基準信号で測定され、ＵＥによって報告されるチャネル品質に基づく（ＤＬチャネル品質についての定期的なＣＳＩ報告を参照）。送信信頼性は、スケジューリングアルゴリズムで選択することができ、すなわち、適切な送信フォーマット（例えば、変調および符号化方式の堅牢性、制御されたＵＬ電力）がＵＥの無線チャネル状態に対して選択されるリンクアダプテーションによって選択することができる。HARQ フィードバックに基づく再送信もスケジューラによって制御されます。HARQ ループのフィードバック送信では遅延が発生しますが、短い送信フォーマット、サブスロット フィードバック レポート、および PUCCH キャリア スイッチングを使用して遅延を最小限に抑える方法があります。HARQ の往復時間遅延を回避する必要がある場合は、スペクトル効率の低下を犠牲にして、繰り返し送信を事前にスケジュールすることもできます。
In dynamic DL scheduling, transmission can be initiated immediately when DL data becomes available in the gNB. However, for dynamic UL scheduling, when data becomes available but no UL resources are available yet, the UE indicates the need for UL resources to the gNB via a (single bit) scheduling request message in the UL control channel. When UL resources are scheduled, the UE can transmit its data and may include a buffer status report that indicates the exact amount of data per logical channel still left to be sent. More UL resources may be scheduled accordingly. To avoid the latency introduced in the scheduling request loop, UL radio resources can also be pre-scheduled.
動的 DL スケジューリングでは、DL データが gNB で利用可能になるとすぐに送信を開始できます。ただし、動的 UL スケジューリングの場合、データは利用可能になっても UL リソースがまだ利用できない場合、UE は UL 制御チャネル内の (単一ビット) スケジューリング要求メッセージを介して gNB に UL リソースの必要性を示します。UL リソースがスケジュールされると、UE はデータを送信でき、論理チャネルごとにまだ送信されていない正確なデータ量を示すバッファ ステータス レポートを含めることができます。それに応じて、より多くのＵＬリソースがスケジュールされる可能性がある。スケジューリング要求ループで生じる遅延を回避するために、UL 無線リソースを事前にスケジュールすることもできます。
In particular, for periodical traffic patterns, the pre-scheduling can rely on the scheduling features DL Semi-Persistent Scheduling (SPS) and UL Configured Grant (CG). With these features, periodically recurring resources can be assigned in DL and UL. Multiple parallels of those configurations are supported in order to serve multiple parallel traffic flows of the same UE.
特に、周期的なトラフィック パターンの場合、事前スケジューリングはスケジューリング機能である DL Semi-Persistent Scheduling (SPS) および UL Configured Grant (CG) に依存できます。これらの機能を使用すると、DL および UL で定期的に繰り返されるリソースを割り当てることができます。同じ UE の複数の並列トラフィック フローに対応するために、これらの構成の複数の並列がサポートされます。
To support QoS enforcement in the case of mixed traffic with different QoS requirements, several features have recently been introduced. These features allow different periodical critical QoS flows to be served, together with best-effort transmissions, by the same UE. These features include the following:
異なる QoS 要件を持つ混合トラフィックの場合に QoS 強制をサポートするために、最近いくつかの機能が導入されました。これらの機能により、異なる定期的なクリティカル QoS フローを、ベストエフォート送信とともに同じ UE によって提供できるようになります。これらの機能には次のものが含まれます。
* UL logical channel transmission restrictions, allowing logical channels of certain QoS to only be mapped to intended UL resources of a certain frequency carrier, slot length, or CG configuration.
* UL 論理チャネル送信制限。特定の QoS の論理チャネルを、特定の周波数キャリア、スロット長、または CG 構成の対象の UL リソースにのみマッピングできるようにします。
* intra-UE preemption and multiplexing, allowing critical UL transmissions to either preempt non-critical transmissions or be multiplexed with non-critical transmissions keeping different reliability targets.
* UE 内プリエンプションと多重化により、クリティカルな UL 送信が非クリティカルな送信をプリエンプトするか、異なる信頼性目標を維持しながら非クリティカルな送信と多重化されることが可能になります。
When multiple frequency carriers are aggregated, duplicate parallel transmissions can be employed (beside repeated transmissions on one carrier). This is possible in the Carrier Aggregation (CA) architecture where those carriers originate from the same gNB or in the Dual Connectivity (DC) architecture where the carriers originate from different gNBs (i.e., the UE is connected to two gNBs in this case). In both cases, transmission reliability is improved by this means of providing frequency diversity.
複数の周波数キャリアが集約される場合、(1 つのキャリアでの繰り返し送信に加えて) 重複した並列送信を使用できます。これは、キャリアが同じ gNB から発信されるキャリア アグリゲーション (CA) アーキテクチャ、またはキャリアが異なる gNB から発信されるデュアル コネクティビティ (DC) アーキテクチャで可能です (つまり、この場合、UE は 2 つの gNB に接続されます)。どちらの場合も、周波数ダイバーシティを提供するこの手段により、送信の信頼性が向上します。
In addition to licensed spectrum, a 5G system can also utilize unlicensed spectrum to offload non-critical traffic. This version of NR, called NR-U, is part of 3GPP Release 16. The central scheduling approach also applies for unlicensed radio resources and the mandatory channel access mechanisms for unlicensed spectrum (e.g., Listen Before Talk (LBT) is supported in NR-U). This way, by using NR, operators have and can control access to both licensed and unlicensed frequency resources.
5G システムは、ライセンスのあるスペクトルに加えて、ライセンスのないスペクトルを利用して、重要でないトラフィックをオフロードすることもできます。NR-U と呼ばれるこのバージョンの NR は、3GPP リリース 16 の一部です。集中スケジューリング アプローチは、ライセンスのない無線リソースとライセンスのないスペクトルの必須チャネル アクセス メカニズムにも適用されます (たとえば、Listen Before Talk (LBT) は NR-U でサポートされています)。このように、NR を使用することで、通信事業者はライセンスのある周波数リソースとライセンスのない周波数リソースの両方へのアクセスを制御できるようになります。
Recent 3GPP releases have introduced various features to support multiple aspects of Time-Sensitive Communication (TSC), which includes Time-Sensitive Networking (TSN) and beyond, as described in this section.
最近の 3GPP リリースでは、このセクションで説明するように、Time-Sensitive Networking (TSN) 以降を含む Time-Sensitive Communication (TSC) の複数の側面をサポートするさまざまな機能が導入されました。
The main objective of TSN is to provide guaranteed data delivery within a guaranteed time window (i.e., bounded low latency). IEEE 802.1 TSN [IEEE802.1TSN] is a set of open standards that provide features to enable deterministic communication on standard IEEE 802.3 Ethernet [IEEE802.3]. TSN standards can be seen as a toolbox for traffic shaping, resource management, time synchronization, and reliability.
TSN の主な目的は、保証された時間枠内で保証されたデータ配信 (つまり、制限された低遅延) を提供することです。IEEE 802.1 TSN [IEEE802.1TSN] は、標準 IEEE 802.3 イーサネット [IEEE802.3] 上で確定的な通信を可能にする機能を提供する一連のオープン標準です。TSN 標準は、トラフィック シェーピング、リソース管理、時刻同期、および信頼性のためのツールボックスとして見ることができます。
A TSN stream is a data flow between one end station (talker) to another end station (listener). In the centralized configuration model, TSN bridges are configured by the Central Network Controller (CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the TSN stream through the network. Time-based traffic shaping provided by scheduled traffic [IEEE802.1Qbv] may be used to achieve bounded low latency. The TSN tool for time synchronization is the generalized Precision Time Protocol (gPTP) [IEEE802.1AS], which provides reliable time synchronization that can be used by end stations and by other TSN tools (e.g., scheduled traffic [IEEE802.1Qbv]). High availability, as a result of ultra-reliability, is provided for data flows by the Frame Replication and Elimination for Reliability (FRER) mechanism [IEEE802.1CB].
TSN ストリームは、あるエンド ステーション (トーカー) と別のエンド ステーション (リスナー) の間のデータ フローです。集中構成モデルでは、TSN ブリッジは中央ネットワーク コントローラー (CNC) [IEEE802.1Qcc] によって構成され、ネットワークを介して TSN ストリームに確定的な接続を提供します。スケジュールされたトラフィック [IEEE802.1Qbv] によって提供される時間ベースのトラフィック シェーピングを使用して、制限された低遅延を達成することができます。時刻同期用の TSN ツールは、一般化された Precision Time Protocol (gPTP) [IEEE802.1AS] であり、エンド ステーションや他の TSN ツール (スケジュールされたトラフィック [IEEE802.1Qbv] など) で使用できる信頼性の高い時刻同期を提供します。超高信頼性の結果として、高可用性は、FRER (Frame Replication and Elimination for Reliability) メカニズム [IEEE802.1CB] によってデータ フローに提供されます。
3GPP Release 16 includes integration of 5G with TSN, i.e., specifies functions for the 5G System (5GS) to deliver TSN streams so that their QoS requirements are met. A key aspect of the integration is that, from the rest of the network, the 5GS appears as a set of TSN bridges (in particular, one virtual bridge per User Plane Function (UPF) on the user plane). The 5GS includes TSN Translator (TT) functionality for the adaptation of the 5GS to the TSN bridged network and for hiding the 5GS internal procedures. The 5GS provides the following components:
3GPP リリース 16 には、5G と TSN の統合が含まれています。つまり、5G システム (5GS) が QoS 要件を満たすように TSN ストリームを配信する機能を指定します。統合の重要な側面は、ネットワークの残りの部分からは 5GS が TSN ブリッジのセットとして見えることです (特に、ユーザー プレーン上のユーザー プレーン機能 (UPF) ごとに 1 つの仮想ブリッジ)。5GS には、5GS を TSN ブリッジ ネットワークに適応させ、5GS の内部手順を隠蔽するための TSN Translator (TT) 機能が含まれています。5GS は次のコンポーネントを提供します。
1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully centralized configuration model
1. 完全集中型構成モデルの [IEEE802.1Qcc] に準拠した、TSN コントローラへのインターフェース
2. time synchronization via reception and transmission of gPTP PDUs [IEEE802.1AS]
2. gPTP PDUの送受信による時刻同期[IEEE802.1AS]
3. low latency, which allows integration with scheduled traffic [IEEE802.1Qbv]
3. 低遅延により、スケジュールされたトラフィックとの統合が可能 [IEEE802.1Qbv]
4. reliability, which allows integration with FRER [IEEE802.1CB]
4. FRER [IEEE802.1CB] との統合を可能にする信頼性
3GPP Release 17 [TS23501] introduced enhancements to generalize support for TSC beyond TSN. This includes IP communications to provide time-sensitive services (e.g., to Video, Imaging, and Audio for Professional Applications (VIAPA)). The system model of 5G acting as a "TSN bridge" in Release 16 has been reused to enable the 5GS acting as a "TSC node" in a more generic sense (which includes TSN bridge and IP node). In the case of TSC that does not involve TSN, requirements are given via exposure interfaces, and the control plane provides the service based on QoS and time synchronization requests from an Application Function (AF).
3GPP リリース 17 [TS23501] では、TSN を超えて TSC のサポートを一般化するための機能拡張が導入されました。これには、時間に敏感なサービスを提供するための IP 通信が含まれます (例: プロフェッショナル アプリケーション向けビデオ、イメージング、およびオーディオ (VIAPA))。リリース 16 で「TSN ブリッジ」として機能する 5G のシステム モデルは、5GS がより一般的な意味での「TSC ノード」（TSN ブリッジと IP ノードを含む）として機能できるようにするために再利用されています。TSN を含まない TSC の場合、要件はエクスポージャー インターフェイスを介して与えられ、コントロール プレーンはアプリケーション機能 (AF) からの QoS および時刻同期要求に基づいてサービスを提供します。
Figure 7 shows an illustration of 5G-TSN integration where an industrial controller (Ind Ctrlr) is connected to industrial Input/ Output devices (I/O dev) via 5G. The 5GS can directly transport Ethernet frames since Release 15; thus, end-to-end Ethernet connectivity is provided. The 5GS implements the required interfaces towards the TSN controller functions such as the CNC, thus adapting to the settings of the TSN network. A 5G user plane virtual bridge interconnects TSN bridges or connects end stations (e.g., I/O devices to the TSN network). TTs, i.e., the Device-Side TSN Translator (DS-TT) at the UE and the Network-Side TSN Translator (NW-TT) at the UPF, have a key role in the interconnection. Note that the introduction of 5G brings flexibility in various aspects, e.g., a more flexible network topology because a wireless hop can replace several wireline hops, thus significantly reducing the number of hops end to end. [TSN5G] dives more into the integration of 5G with TSN.
図 7 は、産業用コントローラー (Ind Ctrlr) が 5G 経由で産業用入出力デバイス (I/O dev) に接続されている 5G-TSN 統合の図を示しています。5GS は、リリース 15 以降、イーサネット フレームを直接転送できるようになりました。したがって、エンドツーエンドのイーサネット接続が提供されます。5GS は、CNC などの TSN コントローラー機能に必要なインターフェイスを実装し、TSN ネットワークの設定に適応します。5G ユーザー プレーン仮想ブリッジは、TSN ブリッジを相互接続するか、エンド ステーション (たとえば、I/O デバイスを TSN ネットワークに接続) を接続します。TT、つまり UE のデバイス側 TSN トランスレータ (DS-TT) と UPF のネットワーク側 TSN トランスレータ (NW-TT) は、相互接続において重要な役割を果たします。5G の導入により、さまざまな側面で柔軟性がもたらされることに注意してください。たとえば、無線ホップがいくつかの有線ホップを置き換えることができるため、より柔軟なネットワーク トポロジーが実現し、エンドツーエンドのホップ数が大幅に削減されます。[TSN5G] では、5G と TSN の統合について詳しく説明します。
+------------------------------+
| 5G System |
| +---+|
| +-+ +-+ +-+ +-+ +-+ |TSN||
| | | | | | | | | | | |AF |......+
| +++ +++ +++ +++ +++ +-+-+| .
| | | | | | | | .
| -+---+---++--+-+-+--+-+- | .
| | | | | | +--+--+
| +++ +++ +++ +++ | | TSN |
| | | | | | | | | | |Ctrlr+.......+
| +++ +++ +++ +++ | +--+--+ .
| | . .
| | . .
| +..........................+ | . .
| . Virtual Bridge . | . .
+---+ | . +--+--+ +---+ +---+--+ . | +--+---+ .
|I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ .
|dev| | . |TT| | | | | |TT| . | |bridge| | .
+---+ | . +--+--+ +---+ +---+--+ . | +------+ | .
| +..........................+ | . +-+-+-+
| | . | Ind |
| +..........................+ | . |Ctrlr|
| . Virtual Bridge . | . +-+---+
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ |
|I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+
|dev| |bridge| | . |TT| | | | | |TT| . | |bridge|
+---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+
| +..........................+ |
+------------------------------+
<----------------- end-to-end Ethernet ------------------->
Figure 7: 5G - TSN Integration
図 7: 5G - TSN の統合
NR supports accurate reference time synchronization in 1 µs accuracy level. Since NR is a scheduled system, an NR UE and a gNB are tightly synchronized to their OFDM symbol structures. A 5G internal reference time can be provided to the UE via broadcast or unicast signaling, associating a known OFDM symbol to this reference clock. The 5G internal reference time can be shared within the 5G network (i.e., radio and core network components). Release 16 has introduced interworking with gPTP for multiple time domains, where the 5GS acts as a virtual gPTP time-aware system and supports the forwarding of gPTP time synchronization information between end stations and bridges through the 5G user plane TTs. These account for the residence time of the 5GS in the time synchronization procedure. One special option is when the 5GS internal reference time is not only used within the 5GS, but also to the rest of the devices in the deployment, including connected TSN bridges and end stations. Release 17 includes further improvements (i.e., methods for propagation delay compensation in RAN), further improving the accuracy for time synchronization over the air, as well as the possibility for the TSN grandmaster clock to reside on the UE side. More extensions and flexibility were added to the time synchronization service, making it general for TSC and providing additional support for other types of clocks and time distribution such as boundary clocks and transparent clocks (both peer-to-peer and end-to-end) aside from the time-aware system used for TSN. Additionally, it is possible to use internal access stratum signaling to distribute timing (and not the usual (g)PTP messages), for which the required accuracy can be provided by the AF [TS23501]. The same time synchronization service is expected to be further extended and enhanced in Release 18 to support Timing Resiliency (according to study item [SP211634]), where the 5G system can provide a backup or alternative timing source for the failure of the local GNSS source (or other primary timing source) used by the vertical.
NR は、1 μs の精度レベルでの正確な基準時間同期をサポートします。NR はスケジュールされたシステムであるため、NR UE と gNB はそれぞれの OFDM シンボル構造に厳密に同期されています。5G 内部基準時間は、既知の OFDM シンボルをこの基準クロックに関連付けて、ブロードキャストまたはユニキャスト シグナリングを介して UE に提供できます。5G 内部基準時間は、5G ネットワーク (つまり、無線およびコア ネットワーク コンポーネント) 内で共有できます。リリース 16 では、複数の時間ドメインでの gPTP とのインターワーキングが導入されており、5GS は仮想 gPTP 時間認識システムとして機能し、5G ユーザー プレーン TT を介したエンド ステーションとブリッジ間の gPTP 時間同期情報の転送をサポートします。これらは、時刻同期手順における 5GS の滞留時間を考慮します。1 つの特別なオプションは、5GS 内部基準時間が 5GS 内だけでなく、接続されている TSN ブリッジやエンド ステーションなど、展開内の残りのデバイスにも使用される場合です。リリース 17 にはさらなる改善 (つまり、RAN における伝播遅延補償の方法) が含まれており、無線での時刻同期の精度がさらに向上し、TSN グランドマスター クロックが UE 側に常駐する可能性も高まります。時刻同期サービスにはさらなる拡張機能と柔軟性が追加され、TSC にとって一般的なサービスとなり、TSN に使用される時刻認識システムとは別に、境界クロックや透過クロック (ピアツーピアとエンドツーエンドの両方) など、他のタイプのクロックと時刻配信のサポートが追加されました。さらに、内部アクセス層シグナリングを使用して（通常の (g)PTP メッセージではなく）タイミングを配布することが可能であり、必要な精度は AF [TS23501] によって提供できます。同時同期サービスは、リリース 18 でさらに拡張および強化され、タイミング復元力 (研究項目 [SP211634] による) をサポートする予定です。これにより、5G システムは、垂直方向で使用されるローカル GNSS ソース (または他の主要なタイミング ソース) の障害に対するバックアップまたは代替のタイミング ソースを提供できます。
IETF DetNet is the technology to support time-sensitive communications at the IP layer. 3GPP Release 18 includes a study [TR2370046] on interworking between 5G and DetNet. Along the TSC framework introduced for Release 17, the 5GS acts as a DetNet node for the support of DetNet; see Figure 7.1-1 in [TR2370046]. The study provides details on how the 5GS is exposed by the Time Sensitive Communication and Time Synchronization Function (TSCTSF) to the DetNet controller as a router on a per-UPF granularity (similarly to the per-UPF Virtual TSN Bridge granularity shown in Figure 7). In particular, it lists the parameters that are provided by the TSCTSF to the DetNet controller. The study also includes how the TSCTSF maps DetNet flow parameters to 5G QoS parameters. Note that TSN is the primary subnetwork technology for DetNet. Thus, the work on DetNet over TSN, e.g., [RFC9023], can be leveraged via the TSN support built in 5G.
IETF DetNet は、時間に敏感な通信を IP 層でサポートするテクノロジーです。3GPP リリース 18 には、5G と DetNet 間のインターワーキングに関する研究 [TR2370046] が含まれています。リリース 17 で導入された TSC フレームワークに沿って、5GS は DetNet をサポートする DetNet ノードとして機能します。[TR2370046]の図 7.1-1 を参照してください。この調査では、5GS が Time Sensitive Communication and Time Synchronization Function (TSCTSF) によって UPF 単位の粒度 (図 7 に示す UPF 単位の仮想 TSN ブリッジ粒度と同様) でルーターとして DetNet コントローラーにどのように公開されるかについて詳しく説明しています。特に、TSCTSF によって DetNet コントローラーに提供されるパラメーターをリストします。この研究には、TSCTSF が DetNet フロー パラメータを 5G QoS パラメータにマッピングする方法も含まれています。TSN は DetNet の主要なサブネットワーク テクノロジであることに注意してください。したがって、TSN を介した DetNet に関する作業 ([RFC9023] など) は、5G に組み込まれた TSN サポートを介して活用できます。
Redundancy architectures were specified in order to provide reliability against any kind of failure on the radio link or nodes in the RAN and the core network. Redundant user plane paths can be provided based on the dual connectivity architecture, where the UE sets up two PDU sessions towards the same data network, and the 5G system makes the paths of the two PDU sessions independent as illustrated in Figure 8. There are two PDU sessions involved in the solution: The first spans from the UE via gNB1 to UPF1, acting as the first PDU session anchor, while the second spans from the UE via gNB2 to UPF2, acting as second the PDU session anchor.
冗長アーキテクチャは、RAN およびコア ネットワーク内の無線リンクまたはノード上のあらゆる種類の障害に対する信頼性を提供するために指定されました。冗長ユーザー プレーン パスは、デュアル接続アーキテクチャに基づいて提供できます。図 8 に示すように、UE が同じデータ ネットワークに向けて 2 つの PDU セッションをセットアップし、5G システムが 2 つの PDU セッションのパスを独立させます。ソリューションには 2 つの PDU セッションが含まれます。最初のセッションは、UE から gNB1 経由で UPF1 に広がり、最初の PDU セッション アンカーとして機能します。一方、2 番目のセッションは、UE から gNB2 経由で UPF2 に広がり、2 番目の PDU セッション アンカーとして機能します。PDU セッション アンカー。
The independent paths may continue beyond the 3GPP network. Redundancy Handling Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A (the device) and in Host B (the network). RHF can implement replication and elimination functions as per [IEEE802.1CB] or the Packet Replication, Elimination, and Ordering Functions (PREOF) of IETF DetNet [RFC8655].
独立したパスは 3GPP ネットワークを越えて続く場合があります。冗長性処理機能 (RHF) は、5GS の外部、つまりホスト A (デバイス) とホスト B (ネットワーク) に展開されます。RHF は、[IEEE802.1CB] または IETF DetNet [RFC8655] のパケット複製、削除、および順序付け機能 (PREOF) に従って、複製および削除機能を実装できます。
+........+
. Device . +------+ +------+ +------+
. . + gNB1 +--N3--+ UPF1 |--N6--+ |
. ./+------+ +------+ | |
. +----+ / | |
. | |/. | |
. | UE + . | DN |
. | |\. | |
. +----+ \ | |
. .\+------+ +------+ | |
+........+ + gNB2 +--N3--+ UPF2 |--N6--+ |
+------+ +------+ +------+
Figure 8: Reliability with Single UE
図 8: 単一 UE の信頼性
An alternative solution is that multiple UEs per device are used for user plane redundancy as illustrated in Figure 9. Each UE sets up a PDU session. The 5GS ensures that the PDU sessions of the different UEs are handled independently internal to the 5GS. There is no single point of failure in this solution, which also includes RHF outside of the 5G system, e.g., as per FRER [IEEE802.1CB] or PREOF [RFC8655] specifications.
別の解決策は、図 9 に示すように、ユーザー プレーンの冗長性のためにデバイスごとに複数の UE を使用することです。各 UE は PDU セッションをセットアップします。5GS は、さまざまな UE の PDU セッションが 5GS の内部で独立して処理されることを保証します。このソリューションには単一障害点がなく、たとえば FRER [IEEE802.1CB] または PREOF [RFC8655] 仕様に従って、5G システム外部の RHF も含まれます。
+.........+
. Device .
. .
. +----+ . +------+ +------+ +------+
. | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ |
. +----+ . +------+ +------+ | |
. . | DN |
. +----+ . +------+ +------+ | |
. | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ |
. +----+ . +------+ +------+ +------+
. .
+.........+
Figure 9: Reliability with Dual UE
図 9: デュアル UE の信頼性
Note that the abstraction provided by the RHF and the location of the RHF outside of the 5G system allow 5G to support integration for reliability with both TSN FRER [IEEE802.1CB] and DetNet PREOF [RFC8655], as they both rely on the same concept.
RHF によって提供される抽象化と 5G システム外の RHF の位置により、5G は TSN FRER [IEEE802.1CB] と DetNet PREOF [RFC8655] の両方との信頼性を高めるための統合をサポートできます。これらは両方とも同じ概念に依存しているためです。
One of the main pillars of the modern Air Traffic Management (ATM) system is the existence of a communication infrastructure that enables efficient aircraft guidance and safe separation in all phases of flight. Although current systems are technically mature, they suffer from the VHF band's increasing saturation in high-density areas and the limitations posed by analog radio. Therefore, aviation (globally and in the European Union (EU) in particular) strives for a sustainable modernization of the aeronautical communication infrastructure.
最新の航空交通管理 (ATM) システムの主な柱の 1 つは、飛行のすべての段階で効率的な航空機の誘導と安全な分離を可能にする通信インフラストラクチャの存在です。現在のシステムは技術的には成熟していますが、高密度エリアでの VHF 帯域の飽和の増加と、アナログ無線による制限に悩まされています。したがって、航空業界 (世界的に、特に欧州連合 (EU) において) は、航空通信インフラの持続可能な近代化に努めています。
In the long term, ATM communication shall transition from analog VHF voice and VHF Digital Link (VDL) Mode 2 communication to more spectrum-efficient digital data communication. The European ATM Master Plan foresees this transition to be realized for terrestrial communications by the development and implementation of the L-band Digital Aeronautical Communications System (LDACS).
長期的には、ATM 通信はアナログ VHF 音声および VHF デジタル リンク (VDL) モード 2 通信から、よりスペクトル効率の高いデジタル データ通信に移行することになります。欧州 ATM マスター プランでは、この移行は、L バンド デジタル航空通信システム (LDACS) の開発と実装によって地上通信で実現されると予測しています。
LDACS has been designed with applications related to the safety and regularity of the flight in mind. It has therefore been designed as a deterministic wireless data link (as far as possible).
LDACS は、飛行の安全性と規則性に関するアプリケーションを念頭に置いて設計されています。したがって、(可能な限り) 確定的な無線データ リンクとして設計されています。
It is a secure, scalable, and spectrum-efficient data link with embedded navigation capability; thus, it is the first truly integrated Communications, Navigation, and Surveillance (CNS) system recognized by the International Civil Aviation Organization (ICAO). During flight tests, the LDACS capabilities have been successfully demonstrated. A viable rollout scenario has been developed, which allows gradual introduction of LDACS with immediate use and revenues. Finally, ICAO is developing LDACS standards to pave the way for the future.
これは、ナビゲーション機能が組み込まれた、安全でスケーラブルでスペクトル効率の高いデータ リンクです。したがって、これは国際民間航空機関 (ICAO) によって認められた初の真に統合された通信、航法、および監視 (CNS) システムです。飛行テスト中に、LDACS 機能が正常に実証されました。実行可能なロールアウト シナリオが開発されており、LDACS を段階的に導入し、すぐに使用して収益を得ることができます。最後に、ICAO は将来への道を開くために LDACS 標準を開発しています。
LDACS shall enable IPv6-based air-ground communication related to the safety and regularity of the flight. The particular challenge is that no new frequencies can be made available for terrestrial aeronautical communication. It was thus necessary to develop procedures to enable the operation of LDACS in parallel with other services in the same frequency band; see [RFC9372] for more information.
LDACS は、飛行の安全性と規則性に関連する IPv6 ベースの空地間通信を可能にするものとします。特に問題となるのは、地上航空通信に新しい周波数を利用できないことです。したがって、同じ周波数帯域で他のサービスと並行して LDACS を動作できるようにする手順を開発する必要がありました。詳細については、[RFC9372] を参照してください。
The development of LDACS has already made substantial progress in the Single European Sky ATM Research (SESAR) framework, and it is currently being continued in the follow-up program, SESAR2020 [RIH18]. A key objective of the SESAR activities is to develop, implement, and validate a modern aeronautical data link able to evolve with aviation needs over the long term. To this end, an LDACS specification has been produced [GRA19] and is continuously updated; transmitter demonstrators were developed to test the spectrum compatibility of LDACS with legacy systems operating in the L-band [SAJ14], and the overall system performance was analyzed by computer simulations, indicating that LDACS can fulfill the identified requirements [GRA11].
LDACS の開発は、Single European Sky ATM Research (SESAR) フレームワークにおいてすでに大幅な進歩を遂げており、現在、フォローアップ プログラムである SESAR2020 [RIH18] で継続されています。SESAR 活動の主な目的は、航空ニーズに合わせて長期的に進化できる最新の航空データ リンクを開発、実装、検証することです。この目的のために、LDACS 仕様が作成され [GRA19]、継続的に更新されています。送信機のデモンストレーターは、L バンドで動作するレガシー システムと LDACS のスペクトル互換性をテストするために開発され [SAJ14]、システム全体のパフォーマンスがコンピューター シミュレーションによって分析され、LDACS が特定された要件を満たすことができることが示されました [GRA11]。
LDACS standardization within the framework of the ICAO started in December 2016. The ICAO standardization group has produced an initial Standards and Recommended Practices (SARPs) document [ICAO18]. The SARPs document defines the general characteristics of LDACS.
ICAO の枠組み内での LDACS 標準化は、2016 年 12 月に開始されました。ICAO 標準化グループは、最初の標準および推奨慣行 (SARP) 文書 [ICAO18] を作成しました。SARP 文書では、LDACS の一般的な特性が定義されています。
Up to now, the LDACS standardization has been focused on the development of the Physical (PHY) layer and the data link layer; only recently have higher layers come into the focus of the LDACS development activities. There is currently no "IPv6 over LDACS" specification; however, SESAR2020 has started the testing of IPv6-based LDACS testbeds. The IPv6 architecture for the aeronautical telecommunication network is called the Future Communications Infrastructure (FCI). FCI shall support QoS, diversity, and mobility under the umbrella of the "multi-link concept". This work is conducted by the ICAO WG-I Working Group.
これまで、LDACS 標準化は物理 (PHY) 層とデータ リンク層の開発に焦点を当ててきました。上位層が LDACS 開発活動の焦点になり始めたのはつい最近のことです。現在、「IPv6 over LDACS」仕様はありません。ただし、SESAR2020 では、IPv6 ベースの LDACS テストベッドのテストが開始されました。航空通信ネットワークの IPv6 アーキテクチャは、Future Communications Infrastructure (FCI) と呼ばれます。FCI は、「マルチリンク概念」の傘下で QoS、ダイバーシティ、およびモビリティをサポートします。この作業は、ICAO WG-I 作業グループによって実施されます。
In addition to standardization activities, several industrial LDACS prototypes have been built. One set of LDACS prototypes has been evaluated in flight trials, confirming the theoretical results predicting the system performance [GRA18] [BEL22] [GRA23].
標準化活動に加えて、いくつかの産業用 LDACS プロトタイプが構築されています。1 セットの LDACS プロトタイプが飛行試験で評価され、システム性能を予測する理論的結果が確認されました [GRA18] [BEL22] [GRA23]。
LDACS will become one of several wireless access networks connecting aircraft to the Aeronautical Telecommunications Network (ATN). The LDACS access network contains several ground stations, each of which provides one LDACS radio cell. The LDACS air interface is a cellular data link with a star topology connecting aircraft to ground stations with a full duplex radio link. Each ground station is the centralized instance controlling all air-ground communications within its radio cell.
LDACS は、航空機を航空電気通信ネットワーク (ATN) に接続するいくつかの無線アクセス ネットワークの 1 つになります。LDACS アクセス ネットワークにはいくつかの地上局が含まれており、それぞれが 1 つの LDACS 無線セルを提供します。LDACS エア インターフェイスは、全二重無線リンクで航空機を地上局に接続するスター トポロジを備えたセルラー データ リンクです。各地上局は、その無線セル内のすべての空地上通信を制御する集中インスタンスです。
The user data rate of LDACS is 315 kbit/s to 1428 kbit/s on the forward link (FL) and 294 kbit/s to 1390 kbit/s on the reverse link (RL), depending on coding and modulation. Due to strong interference from legacy systems in the L-band, the most robust coding and modulation should be expected for initial deployment, i.e., 315 kbit/ s on the FL and 294 kbit/s on the RL.
LDACS のユーザー データ レートは、コーディングと変調に応じて、フォワード リンク (FL) で 315 kbit/s ～ 1428 kbit/s、リバース リンク (RL) で 294 kbit/s ～ 1390 kbit/s です。L バンドではレガシー システムからの強い干渉があるため、初期導入では最も堅牢な符号化と変調、つまり FL で 315 kbit/s、RL で 294 kbit/s が期待されます。
In addition to the communications capability, LDACS also offers a navigation capability. Ranging data, similar to Distance Measuring Equipment (DME), is extracted from the LDACS communication links between aircraft and LDACS ground stations. This results in LDACS providing an Alternative Position, Navigation, and Timing (APNT) capability to supplement the existing on-board Global Navigation Satellite System (GNSS) without the need for additional bandwidth. Operationally, there will be no difference for pilots whether the navigation data are provided by LDACS or DME. This capability was flight tested and proven during the MICONAV flight trials in 2019 [BAT19].
通信機能に加えて、LDACS はナビゲーション機能も提供します。測距データは、距離測定装置 (DME) と同様に、航空機と LDACS 地上局間の LDACS 通信リンクから抽出されます。これにより、LDACS は、追加の帯域幅を必要とせずに、既存のオンボード全地球航法衛星システム (GNSS) を補完する代替位置、ナビゲーション、およびタイミング (APNT) 機能を提供します。運用上、パイロットにとっては、ナビゲーション データが LDACS によって提供されるか DME によって提供されるかに違いはありません。この機能は、2019 年の MICONAV 飛行試験中に飛行テストされ、証明されました [BAT19]。
In previous works and during the MICONAV flight campaign in 2019, it was also shown that LDACS can be used for surveillance capability. Filip et al. [FIL19] have shown the passive radar capabilities of LDACS, and Automatic Dependence Surveillance - Contract (ADS-C) was demonstrated via LDACS during the flight campaign 2019 [SCH19].
以前の研究と 2019 年の MICONAV 飛行キャンペーン中に、LDACS が監視機能に使用できることも示されました。フィリップら。[FIL19] は LDACS のパッシブ レーダー機能を示し、2019 年の飛行キャンペーン中に LDACS を介して自動依存監視 - 契約 (ADS-C) が実証されました [SCH19]。
Since LDACS has been mainly designed for air traffic management communication, it supports mutual entity authentication, integrity and confidentiality capabilities of user data messages, and some control channel protection capabilities [MAE18] [MAE191] [MAE192] [MAE20].
LDACS は主に航空交通管理通信用に設計されているため、相互エンティティ認証、ユーザー データ メッセージの完全性と機密性の機能、および一部の制御チャネル保護機能 [MAE18] [MAE191] [MAE192] [MAE20] をサポートしています。
Overall, this makes LDACS the world's first truly integrated CNS system and is the most mature, secure, and terrestrial long-range CNS technology for civil aviation worldwide.
全体的に見て、LDACS は世界初の真に統合された CNS システムとなり、世界中の民間航空向けの最も成熟した安全な地上長距離 CNS テクノロジーとなります。
LDACS has its origin in merging parts of the B-VHF [BRA06], B-AMC [SCH08], TIA-902 (P34) [HAI09], and WiMAX IEEE 802.16e [EHA11] technologies. In 2007, the spectrum for LDACS was allocated at the World Radio Conference (WRC).
LDACS は、B-VHF [BRA06]、B-AMC [SCH08]、TIA-902 (P34) [HAI09]、および WiMAX IEEE 802.16e [EHA11] テクノロジーの一部を統合したことに起源を持ちます。2007 年、世界無線会議 (WRC) で LDACS のスペクトルが割り当てられました。
It was decided to allocate the spectrum next to Distance Measuring Equipment (DME), resulting in an in-lay approach between the DME channels for LDAC [SCH14].
スペクトルを距離測定装置 (DME) の隣に割り当てることが決定され、その結果、LDAC [SCH14] の DME チャネル間のインレイ アプローチが実現しました。
LDACS is currently being standardized by ICAO and several rollout strategies are discussed.
LDACS は現在 ICAO によって標準化されており、いくつかの展開戦略が議論されています。
The LDACS data link provides enhanced capabilities to existing aeronautical communications infrastructures, enabling them to better support user needs and new applications. The deployment scalability of LDACS allows its implementation to start in areas where it is most needed to immediately improve the performance of and already-fielded infrastructure. Later, the deployment is extended based on operational demand. An attractive scenario for upgrading the existing VHF communication systems by adding an additional LDACS data link is described below.
LDACS データ リンクは、既存の航空通信インフラストラクチャに強化された機能を提供し、ユーザーのニーズと新しいアプリケーションをより適切にサポートできるようにします。LDACS の展開のスケーラビリティにより、既存のインフラストラクチャのパフォーマンスを即座に向上させることが最も必要な領域から実装を開始できます。その後、運用上の需要に基づいて展開が拡張されます。LDACS データ リンクを追加して既存の VHF 通信システムをアップグレードする魅力的なシナリオを以下に説明します。
When considering the current VDL Mode 2 infrastructure and user base, a very attractive win-win situation comes about when the technological advantages of LDACS are combined with the existing VDL Mode 2 infrastructure. LDACS provides at least 50 times more capacity than VDL Mode 2 and is a natural enhancement to the existing VDL Mode 2 business model. The advantage of this approach is that the VDL Mode 2 infrastructure can be fully reused. Beyond that, it opens the way for further enhancements [ICAO19].
現在の VDL モード 2 インフラストラクチャとユーザー ベースを考慮すると、LDACS の技術的利点が既存の VDL モード 2 インフラストラクチャと組み合わされると、非常に魅力的な双方にとって有利な状況が生まれます。LDACS は VDL モード 2 の少なくとも 50 倍の容量を提供し、既存の VDL モード 2 ビジネス モデルを自然に強化します。このアプローチの利点は、VDL モード 2 インフラストラクチャを完全に再利用できることです。それを超えて、さらなる機能強化への道が開かれます[ICAO19]。
As LDACS is a ground-based digital communications system for flight guidance and communications related to safety and regularity of flight, time-bounded deterministic arrival times for safety critical messages are a key feature for its successful deployment and rollout.
LDACS は、安全性と飛行の規則性に関連する飛行誘導と通信のための地上ベースのデジタル通信システムであるため、安全性に関する重要なメッセージの時間制限付きの確定的な到着時間は、導入と展開を成功させるための重要な機能です。
Up to 512 Aircraft Stations (ASes) communicate to an LDACS Ground Station (GS) in the reverse link (RL). A GS communicates to an AS in the forward link (FL). Via an Access-Router (AC-R), GSs connect the LDACS subnetwork to the global Aeronautical Telecommunications Network (ATN) to which the corresponding Air Traffic Services (ATS) and Aeronautical Operational Control (AOC) end systems are attached.
最大 512 の航空機ステーション (AS) が、リバース リンク (RL) の LDACS 地上ステーション (GS) と通信します。GS は、順方向リンク (FL) で AS と通信します。GS は、アクセス ルータ（AC-R）を介して、LDACS サブネットワークを、対応する航空交通サービス（ATS）および航空運用管理（AOC）エンド システムが接続されているグローバル航空電気通信ネットワーク（ATN）に接続します。
The protocol stack of LDACS is implemented in the AS and GS; it consists of the Physical (PHY) layer with five major functional blocks above it. Four are placed in the data link layer (DLL) of the AS and GS:
LDACS のプロトコル スタックは AS と GS に実装されます。これは、物理 (PHY) 層とその上の 5 つの主要な機能ブロックで構成されます。4 つは AS と GS のデータ リンク層 (DLL) に配置されます。
1. Medium Access Layer (MAC),
1. 媒体アクセス層 (MAC)、
2. Voice Interface (VI),
2. 音声インターフェース (VI)、
3. Data Link Service (DLS), and
3. データリンクサービス（DLS）、および
4. LDACS Management Entity (LME).
4. LDACS 管理エンティティ (LME)。
The last entity resides within the subnetwork layer: the Subnetwork Protocol (SNP). The LDACS network is externally connected to voice units, radio control units, and the ATN network layer.
最後のエンティティは、サブネットワーク層内に存在する、サブネットワーク プロトコル (SNP) です。LDACS ネットワークは、音声ユニット、無線制御ユニット、および ATN ネットワーク層に外部接続されています。
Communications between the MAC and LME layers is split into four distinct control channels:
MAC 層と LME 層の間の通信は、次の 4 つの異なる制御チャネルに分割されます。
1. the Broadcast Control Channel (BCCH), where LDACS ground stations announce their specific LDACS cell, including physical parameters and cell identification;
1. ブロードキャスト制御チャネル (BCCH)。LDACS 地上局は、物理パラメータやセル ID を含む特定の LDACS セルをアナウンスします。
2. the Random Access Channel (RACH), where LDACS airborne radios can request access to an LDACS cell;
2. ランダム アクセス チャネル (RACH)。LDACS 航空機無線が LDACS セルへのアクセスを要求できます。
3. the Common Control Channel (CCCH), where LDACS ground stations allocate resources to aircraft radios, enabling the airborne side to transmit the user payload; and
3. 共通制御チャネル (CCCH)。LDACS 地上局が航空機無線にリソースを割り当て、航空機側がユーザー ペイロードを送信できるようにします。そして
4. the Dedicated Control Channel (DCCH), where LDACS airborne radios can request user data resources from the LDACS ground station so the airborne side can transmit the user payload.
4. 専用制御チャネル (DCCH)。LDACS 航空機搭載無線機が LDACS 地上局からユーザー データ リソースを要求できるため、航空機側がユーザー ペイロードを送信できます。
Communications between the MAC and DLS layers is handled by the Data Channel (DCH) where the user payload is handled.
MAC 層と DLS 層の間の通信は、ユーザー ペイロードが処理されるデータ チャネル (DCH) によって処理されます。
Figure 10 shows the protocol stack of LDACS as implemented in the AS and GS.
図 10 は、AS および GS に実装された LDACS のプロトコル スタックを示しています。
IPv6 Network Layer
|
|
+------------------+ +----+
| SNP |--| | Subnetwork
| | | | Layer
+------------------+ | |
| | LME|
+------------------+ | |
| DLS | | | Logical Link
| | | | Control Layer
+------------------+ +----+
| |
DCH DCCH/CCCH
| RACH/BCCH
| |
+--------------------------+
| MAC | Medium Access
| | Layer
+--------------------------+
|
+--------------------------+
| PHY | Physical Layer
+--------------------------+
|
|
((*))
FL/RL radio channels
separated by
frequency division duplex
Figure 10: LDACS Protocol Stack in AS and GS
図 10: AS および GS の LDACS プロトコル スタック
The PHY layer provides the means to transfer data over the radio channel. The LDACS ground station supports bidirectional links to multiple aircraft under its control. The FL direction (which is ground to air) and the RL direction (which is air to ground) are separated by frequency division duplex. FL and RL use a 500 kHz channel each. The ground station transmits a continuous stream of OFDM symbols on the FL. In the RL, different aircrafts are separated in time and frequency using a combination of Orthogonal Frequency-Division Multiple Access (OFDMA) and Time-Division Multiple-Access (TDMA). Thus, aircraft transmit discontinuously on the RL with radio bursts sent in precisely defined transmission opportunities allocated by the ground station. The most important service on the PHY layer of LDACS is the PHY time framing service, which indicates that the PHY layer is ready to transmit in a given slot and indicates PHY layer framing and timing to the MAC time framing service. LDACS does not support beam-forming or Multiple Input Multiple Output (MIMO).
PHY 層は、無線チャネル経由でデータを転送する手段を提供します。LDACS 地上局は、その制御下にある複数の航空機への双方向リンクをサポートします。FL 方向 (地上から空中) と RL 方向 (空中から地上) は、周波数分割二重によって分離されます。FL と RL はそれぞれ 500 kHz チャネルを使用します。地上局は、FL 上で OFDM シンボルの連続ストリームを送信します。RL では、直交周波数分割多元接続 (OFDMA) と時分割多元接続 (TDMA) の組み合わせを使用して、異なる航空機が時間と周波数で分離されます。したがって、航空機は、地上局によって割り当てられた正確に定義された送信機会で無線バーストを送信し、RL 上で不連続に送信します。LDACS の PHY 層で最も重要なサービスは PHY タイム フレーミング サービスです。これは、PHY 層が特定のスロットで送信する準備ができていることを示し、PHY 層のフレーミングとタイミングを MAC タイム フレーミング サービスに示します。LDACS は、ビーム フォーミングまたは複数入力複数出力 (MIMO) をサポートしていません。
The data link layer provides the necessary protocols to facilitate concurrent and reliable data transfer for multiple users. The LDACS data link layer is organized in two sublayers: the medium access sublayer and the logical link control sublayer. The medium access sublayer manages the organization of transmission opportunities in slots of time and frequency. The logical link control sublayer provides acknowledged point-to-point logical channels between the aircraft and the ground station using an automatic repeat request protocol. LDACS also supports unacknowledged point-to-point channels and ground-to-air broadcast.
データ リンク層は、複数のユーザーに対する同時かつ信頼性の高いデータ転送を促進するために必要なプロトコルを提供します。LDACS データ リンク層は、媒体アクセス サブレイヤと論理リンク制御サブレイヤの 2 つのサブレイヤで構成されます。メディア アクセス サブレイヤは、時間と周波数のスロットにおける送信機会の構成を管理します。論理リンク制御サブレイヤーは、自動再送要求プロトコルを使用して、航空機と地上局の間に確認済みのポイントツーポイント論理チャネルを提供します。LDACS は、未確認のポイントツーポイント チャネルと地上対空ブロードキャストもサポートします。
Next, the frame structure of LDACS is introduced, followed by a more in-depth discussion of the LDACS medium access.
次に、LDACS のフレーム構造が紹介され、続いて LDACS メディア アクセスについてさらに詳しく説明します。
The LDACS framing structure for FL and RL is based on Super-Frames (SF) of 240 ms duration. Each SF corresponds to 2000 OFDM symbols. The FL and RL SF boundaries are aligned in time (from the view of the GS).
FL および RL の LDACS フレーミング構造は、240 ミリ秒持続時間のスーパー フレーム (SF) に基づいています。各 SF は 2000 個の OFDM シンボルに対応します。FL と RL の SF 境界は、(GS から見て) 時間的に位置合わせされます。
In the FL, an SF contains a broadcast frame with a duration of 6.72 ms (56 OFDM symbols) for the Broadcast Control Channel (BCCH) and four Multi-Frames (MF), each with a duration of 58.32 ms (486 OFDM symbols).
FL では、SF には、ブロードキャスト制御チャネル (BCCH) の持続時間 6.72 ミリ秒 (56 OFDM シンボル) のブロードキャスト フレームと、それぞれ持続時間 58.32 ミリ秒 (486 OFDM シンボル) の 4 つのマルチフレーム (MF) が含まれます。
In the RL, each SF starts with a Random Access (RA) slot with a length of 6.72 ms with two opportunities for sending RL random access frames for the Random Access Channel (RACH), followed by four MFs. These MFs have the same fixed duration of 58.32 ms as in the FL but a different internal structure.
RL では、各 SF は長さ 6.72 ミリ秒のランダム アクセス (RA) スロットで始まり、ランダム アクセス チャネル (RACH) の RL ランダム アクセス フレームを送信する 2 つの機会があり、その後に 4 つの MF が続きます。これらの MF は FL と同じ 58.32 ミリ秒の固定持続時間を持ちますが、内部構造が異なります。
Figures 11 and 12 illustrate the LDACS frame structure. This fixed frame structure allows for the reliable and dependable transmission of data.
図 11 および 12 は、LDACS フレーム構造を示しています。この固定フレーム構造により、信頼性の高いデータ伝送が可能になります。
^
| +------+------------+------------+------------+------------+
| FL | BCCH | MF | MF | MF | MF |
F +------+------------+------------+------------+------------+
r <---------------- Super-Frame (SF) - 240 ms --------------->
e
q +------+------------+------------+------------+------------+
u RL | RACH | MF | MF | MF | MF |
e +------+------------+------------+------------+------------+
n <---------------- Super-Frame (SF) - 240 ms --------------->
c
y
|
----------------------------- Time ------------------------------>
|
Figure 11: SF Structure for LDACS
図 11: LDACS の SF 構造
^
| +-------------+------+-------------+
| FL | DCH | CCCH | DCH |
F +-------------+------+-------------+
r <--- Multi-Frame (MF) - 58.32 ms -->
e
q +------+---------------------------+
u RL | DCCH | DCH |
e +------+---------------------------+
n <--- Multi-Frame (MF) - 58.32 ms -->
c
y
|
-------------------- Time ------------------>
|
Figure 12: MF Structure for LDACS
図 12: LDACS の MF 構造
Next, the LDACS medium access layer is introduced.
次に、LDACS メディア アクセス層が紹介されます。
LDACS medium access is always under the control of the ground station of a radio cell. Any medium access for the transmission of user data has to be requested with a resource request message stating the requested amount of resources and class of service. The ground station performs resource scheduling on the basis of these requests and grants resources with resource allocation messages. Resource request and allocation messages are exchanged over dedicated contention-free control channels.
LDACS 媒体アクセスは常に無線セルの地上局の制御下にあります。ユーザー データを送信するためのメディア アクセスは、要求されたリソースの量とサービス クラスを示すリソース要求メッセージを使用して要求する必要があります。地上局は、これらの要求に基づいてリソースのスケジューリングを実行し、リソース割り当てメッセージでリソースを許可します。リソース要求および割り当てメッセージは、専用の競合のない制御チャネルを介して交換されます。
LDACS has two mechanisms to request resources from the scheduler in the ground station. Resources can either be requested "on demand" or permanently allocated by a LDACS ground station with a given class of service. On the FL, this is done locally in the ground station; on the RL, a dedicated contention-free control channel is used (the Dedicated Control Channel (DCCH); roughly 83 bits every 60 ms). A resource allocation is always announced in the control channel of the FL (Common Control Channel (CCCH); variable sized). Due to the spacing of the RL control channels of every 60 ms, a medium access delay in the same order of magnitude is to be expected.
LDACS には、地上局のスケジューラにリソースを要求する 2 つのメカニズムがあります。リソースは、「オンデマンド」で要求することも、特定のサービス クラスの LDACS 地上局によって永続的に割り当てることもできます。FL では、これは地上局でローカルに行われます。RL では、専用の非競合制御チャネル (専用制御チャネル (DCCH)、60 ミリ秒ごとにおよそ 83 ビット) が使用されます。リソース割り当ては常に FL の制御チャネル (共通制御チャネル (CCCH)、可変サイズ) で発表されます。RL 制御チャネルの間隔が 60 ミリ秒ごとであるため、同程度の中程度のアクセス遅延が予想されます。
Resources can also be requested "permanently". The permanent resource request mechanism supports requesting recurring resources at given time intervals. A permanent resource request has to be canceled by the user (or by the ground station, which is always in control). User data transmissions over LDACS are therefore always scheduled by the ground station, while control data uses statically (i.e., at net entry) allocated recurring resources (DCCH and CCCH). The current specification documents specify no scheduling algorithm. However, performance evaluations so far have used strict priority scheduling and round robin for equal priorities for simplicity. In the current prototype implementations, LDACS classes of service are thus realized as priorities of medium access and not as flows. Note that this can starve out low-priority flows. However, this is not seen as a big problem since safety-related messages always go first in any case. Scheduling of RL resources is done in physical Protocol Data Units (PDU) of 112 bits (or larger if more aggressive coding and modulation is used). Scheduling on the FL is done byte wise since the FL is transmitted continuously by the ground station.
リソースは「永続的に」リクエストすることもできます。永続的なリソース要求メカニズムは、指定された時間間隔での定期的なリソースの要求をサポートします。永続的なリソース要求は、ユーザー (または常に制御している地上局) によってキャンセルされる必要があります。したがって、LDACS を介したユーザー データ送信は常に地上局によってスケジュールされますが、制御データは静的に (つまり、ネット エントリで) 割り当てられた繰り返しリソース (DCCH および CCCH) を使用します。現在の仕様文書では、スケジューリング アルゴリズムは指定されていません。ただし、これまでのパフォーマンス評価では、簡素化のために厳密な優先順位のスケジューリングと同等の優先順位のラウンド ロビンが使用されてきました。したがって、現在のプロトタイプ実装では、LDACS サービス クラスはフローとしてではなく、メディア アクセスの優先順位として実現されます。これにより、優先度の低いフローが枯渇する可能性があることに注意してください。ただし、どのような場合でも安全関連のメッセージが常に最初に表示されるため、これは大きな問題とは見なされません。RL リソースのスケジューリングは、112 ビット (より積極的なコーディングと変調が使用される場合はさらに大きい) の物理プロトコル データ ユニット (PDU) で行われます。FL は地上局によって継続的に送信されるため、FL でのスケジューリングはバイト単位で行われます。
In order to support diversity, LDACS supports handovers to other ground stations on different channels. Handovers may be initiated by the aircraft (break before make) or by the ground station (make before break). Beyond this, FCI diversity shall be implemented by the multi-link concept.
ダイバーシティをサポートするために、LDACS は異なるチャネル上の他の地上局へのハンドオーバーをサポートします。ハンドオーバーは、航空機 (休憩前に休憩) または地上局 (休憩前に休憩) によって開始される場合があります。これを超えて、FCI ダイバーシティはマルチリンク概念によって実装されます。
This document has no IANA actions.
この文書には IANA のアクションはありません。
Most RAW technologies integrate some authentication or encryption mechanisms that are defined outside the IETF. The IETF specifications referenced herein each provide their own security considerations, and the lower-layer technologies used provide their own security at Layer 2.
ほとんどの RAW テクノロジーには、IETF の外部で定義されたいくつかの認証または暗号化メカニズムが統合されています。ここで参照されている IETF 仕様はそれぞれ独自のセキュリティに関する考慮事項を提供しており、使用されている下位層テクノロジはレイヤ 2 で独自のセキュリティを提供します。
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <https://www.rfc-editor.org/info/rfc5673>.
[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>.
[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>.
[RFC9912] Thubert, P., Ed., "Reliable and Available Wireless (RAW)
Architecture", RFC 9912, DOI 10.17487/RFC9912, April 2026,
<https://www.rfc-editor.org/info/rfc9912>.
[Avnu] "Avnu Alliance", <https://www.avnu.org>.
[BAT19] Battista, G., Osechas, O., Narayanan, S., Crespillo, O.G.,
Gerbeth, D., Maeurer, N., Mielke, D., and T. Graeupl,
"Real-Time Demonstration of Integrated Communication and
Navigation Services Using LDACS", Integrated
Communications, Navigation and Surveillance Conference
(ICNS), pp. i-xii, DOI 10.1109/ICNSURV.2019.8735195, 2019,
<https://elib.dlr.de/134475/1/08735195.pdf>.
[BEL22] Bellido-Manganell, M. A., Gräupl, T., Heirich, O., Mäurer,
N., Filip-Dhaubhadel, A., Mielke, D. M., Schalk, L. M.,
Becker, D., Schneckenburger, N., and M. Schnell, "LDACS
Flight Trials: Demonstration and Performance Analysis of
the Future Aeronautical Communications System", IEEE
Transactions on Aerospace and Electronic Systems, vol. 58,
no. 1, pp. 615-634, DOI 10.1109/TAES.2021.3111722,
February 2022,
<https://doi.org/10.1109/TAES.2021.3111722>.
[BRA06] Brandes, S., Schnell, M., Rokitansky, C.-h., Ehammer, M.,
Graeupl, T., Steendam, H., Guenach, M., Rihacek, C., and
B. Haindl, "B-VHF - Selected Simulation Results and Final
Assessment", IEEE 25th Digital Avionics Systems Conference
(DACS), pp. 1-12, DOI 10.1109/DASC.2006.313670, 2006,
<https://doi.org/10.1109/DASC.2006.313670>.
[Cavalcanti1287]
Cavalcanti, D., Venkatesan, G., Cariou, L., and C.
Cordeiro, "TSN support in 802.11 and potential extensions
for TGbe", 10 September 2019,
<https://mentor.ieee.org/802.11/dcn/19/11-19-1287>.
[Cavalcanti_2019]
Cavalcanti, D., Perez-Ramirez, J., Rashid, M. M., Fang,
J., Galeev, M., and K. B. Stanton, "Extending Accurate
Time Distribution and Timeliness Capabilities Over the Air
to Enable Future Wireless Industrial Automation Systems",
Proceedings of the IEEE, vol. 107, no. 6, pp. 1132-1152,
DOI 10.1109/JPROC.2019.2903414, June 2019,
<https://doi.org/10.1109/JPROC.2019.2903414>.
[CCAMP] IETF, "Common Control and Measurement Plane",
<https://datatracker.ietf.org/doc/charter-ietf-ccamp/>.
[CoAP-6TiSCH]
Sudhaakar, R. S., Ed. and P. Zand, "6TiSCH Resource
Management and Interaction using CoAP", Work in Progress,
Internet-Draft, draft-ietf-6tisch-coap-03, 9 March 2015,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
coap-03>.
[EHA11] Ehammer, M., Pschernig, E., and T. Graeupl, "AeroMACS - An
Airport Communications System", 2011 IEEE/AIAA 30th
Digital Avionics Systems Conference, pp. 4C1-1-4C1-16,
DOI 10.1109/DASC.2011.6095903, 2011,
<https://doi.org/10.1109/DASC.2011.6095903>.
[Fang_2021]
Fang, J., Sudhakaran, S., Cavalcanti, D., Cordeiro, C.,
and C. Chen, "Wireless TSN with Multi-Radio Wi-Fi", 2021
IEEE Conference on Standards for Communications and
Networking (CSCN), pp. 105-110,
DOI 10.1109/CSCN53733.2021.9686180, 2021,
<https://doi.org/10.1109/CSCN53733.2021.9686180>.
[FIL19] Filip-Dhaubhadel, A. and D. Shutin, "LDACS- Based Non-
Cooperative Surveillance Multistatic Radar Design and
Detection Coverage Assessment", IEEE/AIAA 38th Digital
Avionics Systems Conference (DASC), pp. 1-10,
DOI 10.1109/DASC43569.2019.9081714, 2019,
<https://doi.org/10.1109/DASC43569.2019.9081714>.
[Ghasempour_2017]
Ghasempour, Y., Silva, C. R. C. M. D., Cordeiro, C., and
E. W. Knightly, "802.11ay: Next-Generation 60 GHz
Communications for 100 Gb/s Wi-Fi", IEEE Communications
Magazine, vol. 55, no. 12, pp. 186-192,
DOI 10.1109/MCOM.2017.1700393, December 2017,
<https://doi.org/10.1109/MCOM.2017.1700393>.
[GRA11] Gräupl, T., "LDACS1 Data Link Layer Evolution of ATN/IPS",
IEEE/AIAA 30th Digital Avionics Systems Conference, pp.
1-28, DOI 10.1109/DASC.2011.6096230, October 2011,
<https://doi.org/10.1109/DASC.2011.6096230>.
[GRA18] Gräupl, T., Schneckenburger, N., Jost, T., Schnell, M.,
Filip, A., Bellido-Manganell, M. A., Mielke, D. M.,
Mäurer, N., Kumar, R., Osechas, O., and G. Battista,
"L-band Digital Aeronautical Communications System (LDACS)
flight trials in the national German project MICONAV",
2018 Integrated Communications, Navigation, Surveillance
Conference (ICNS), pp. 4A2-1-4A2-7,
DOI 10.1109/ICNSURV.2018.8384881, April 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384881>.
[GRA19] Gräupl, T., Rihacek, C., Haindl, B., and Q. Parrod,
"SESAR2020 - PJ14-02-01 - LDACS A/G SPECIFICATION",
EDITION 00.02.02, 16 August 2019, <https://www.ldacs.com/
wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_A
G_Specification_00_02_02-1_0.pdf>.
[GRA23] Gräupl, T., Mielke, D. M., Bellido-Manganell, M. A.,
Jansen, L. J., Mäurer, N., Gürbüz, A., Filip-Dhaubhadel,
A., Schalk, L., Becker, D., Skorepa, M., Wrobel, F.,
Morioka, K., Kurz, S., and J. Meser, "LDACS Flight Trials:
Demonstration of ATS-B2, IPS, and Seamless Mobility", 2023
Integrated Communication, Navigation and Surveillance
Conference (ICNS), pp. 1-13,
DOI 10.1109/ICNS58246.2023.10124329, 2023,
<https://doi.org/10.1109/ICNS58246.2023.10124329>.
[HAI09] Haindl, B., Rihacek, C., Sajatovic, M., Phillips, B.,
Budinger, J., Schnell, M., Kamiano, D., and W. Wilson,
"Improvement of L-DACS1 Design by Combining B-AMC with P34
and WiMAX Technologies", 2009 Integrated Communications,
Navigation and Surveillance Conference, pp. 1-8,
DOI 10.1109/ICNSURV.2009.5172873, May 2009,
<https://doi.org/10.1109/ICNSURV.2009.5172873>.
[ICAO18] International Civil Aviation Organization (ICAO), "L-Band
Digital Aeronautical Communication System (LDACS)",
International Standards and Recommended Practices, Annex
10 - Aeronautical Telecommunications, Vol. III -
Communication Systems, July 2018,
<https://elibrary.icao.int/product/279816>.
[ICAO19] International Civil Aviation Organization (ICAO), "TLDACS
White Paper - A Roll-out Scenario", Communications Panel -
Data Communications Infrastructure Working Group, October
2019, <https://www.ldacs.com/wp-content/uploads/2013/12/
ACP-DCIWG-IP01-LDACS-White-Paper.pdf>.
[IEEE802.11]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE
Std 802.11-2024, DOI 10.1109/IEEESTD.2025.10979691, 2024,
<https://ieeexplore.ieee.org/document/10979691>.
[IEEE802.11ad]
IEEE, "IEEE Standard for Information technology --
Telecommunications and information exchange between
systems -- Local and metropolitan area networks --
Specific requirements-Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications
Amendment 3: Enhancements for Very High Throughput in the
60 GHz Band", IEEE Std 802.11ad-2012,
DOI 10.1109/IEEESTD.2012.6392842, 2012,
<https://ieeexplore.ieee.org/document/6392842/>.
[IEEE802.11ax]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 1:
Enhancements for High-Efficiency WLAN", IEEE Std 802.11ax-
2021, DOI 10.1109/IEEESTD.2021.9442429, 2021,
<https://ieeexplore.ieee.org/document/9442429>.
[IEEE802.11ay]
IEEE, "IEEE Standard for Information Technology --
Telecommunications and Information Exchange between
Systems Local and Metropolitan Area Networks -- Specific
Requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhanced Throughput for Operation in License-exempt Bands
above 45 GHz", IEEE Std 802.11ay-2021,
DOI 10.1109/IEEESTD.2021.9502046, 2021,
<https://ieeexplore.ieee.org/document/9502046/>.
[IEEE802.11be]
IEEE, "IEEE Standard for Information technology --
Telecommunications and information exchange between
systems Local and metropolitan area networks -- Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment 2:
Enhancements for Extremely High Throughput (EHT)", IEEE
Std 802.11be-2024, DOI 10.1109/IEEESTD.2024.11090080,
<https://ieeexplore.ieee.org/document/11090080>.
[IEEE802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
<https://doi.org/10.1109/IEEESTD.2016.7460875>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks -- Timing and Synchronization for Time-Sensitive
Applications", IEEE Std 802.1AS-2020,
DOI 10.1109/IEEESTD.2020.9121845,
<https://doi.org/10.1109/IEEESTD.2020.9121845>.
[IEEE802.1CB]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Frame Replication and Elimination for
Reliability", IEEE Std 802.1CB-2017,
DOI 10.1109/IEEEStd2017.8091139, 2017,
<https://ieeexplore.ieee.org/document/8091139>.
[IEEE802.1Qat]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Virtual Bridged Local Area Networks Amendment
14: Stream Reservation Protocol (SRP)", IEEE Std 802.1Qat-
2010, DOI 10.1109/IEEESTD.2010.5594972,
<https://doi.org/10.1109/IEEESTD.2010.5594972>.
[IEEE802.1Qbv]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks - Amendment 25:
Enhancements for Scheduled Traffic", IEEE Std 802.1Qbv-
2015, DOI 10.1109/IEEESTD.2016.8613095, 2016,
<https://doi.org/10.1109/IEEESTD.2016.8613095>.
[IEEE802.1Qcc]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Bridges and Bridged Networks -- Amendment 31:
Stream Reservation Protocol (SRP) Enhancements and
Performance Improvements", IEEE Std 802.1Qcc-2018,
DOI 10.1109/IEEESTD.2018.8514112,
<https://ieeexplore.ieee.org/document/8514112>.
[IEEE802.1TSN]
IEEE 802.1 Working Group, "Time-Sensitive Networking Task
Group", <http://www.ieee802.org/1/pages/tsn.html>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
DOI 10.1109/IEEESTD.2022.9844436,
<https://ieeexplore.ieee.org/document/9844436>.
[IEEE_doc_11-18-2009-06]
IEEE, "802.11 Real-Time Applications (RTA) Topic Interest
Group (TIG) Report", November 2018,
<https://mentor.ieee.org/802.11/dcn/18/11-18-2009-06-0rta-
rta-report-draft.docx>.
[IMT2020] ITU, "IMT-2020 (a.k.a. "5G")", <https://www.itu.int/en/
ITU-R/study-groups/rsg5/rwp5d/imt-2020/Pages/
default.aspx>.
[ISA100.11a]
ISA, "ISA100 Wireless", ANSI/ISA-100.11a-2011 (IEC 26743),
<https://isa100wci.org/about-isa100-wireless?_gl=1*19xrxgo
*_up*MQ..*_ga*NDczNjkxOTQ1LjE3NjI0NjQ2NDk.*_ga_L2KSW4EHCS*
czE3NjI0NjQ2NDkkbzEkZzEkdDE3NjI0NjQ3MzQkajYwJGwwJGgw>.
[MAE18] Maeurer, N. and A. Bilzhause, "A Cybersecurity
Architecture for the L-band Digital Aeronautical
Communications System (LDACS)", 2018 IEEE/AIAA 37th
Digital Avionics Systems Conference (DASC), pp. 1-10,
DOI 10.1109/DASC.2018.8569878, 2018,
<https://doi.org/10.1109/DASC.2018.8569878>.
[MAE191] Maeurer, N. and C. Schmitt, "Towards Successful
Realization of the LDACS Cybersecurity Architecture: An
Updated Datalink Security Threat- and Risk Analysis",
Integrated Communications, Navigation and Surveillance
Conference (ICNS), pp. 1-13,
DOI 10.1109/ICNSURV.2019.8735139, 2019,
<https://doi.org/10.1109/ICNSURV.2019.8735139>.
[MAE192] Maeurer, N., Graeupl, T., and C. Schmitt, "Evaluation of
the LDACS Cybersecurity Implementation", IEEE/AIAA 38th
Digital Avionics Systems Conference (DASC), pp. 1-10,
DOI 10.1109/DASC43569.2019.9081786, September 2019,
<https://doi.org/10.1109/DASC43569.2019.9081786>.
[MAE20] Maeurer, N., Graeupl, T., Gentsch, C., and C. Schmitt,
"Comparing Different Diffie-Hellman Key Exchange Flavors
for LDACS", AIAA/IEEE 39th Digital Avionics Systems
Conference (DASC), pp. 1-10,
DOI 10.1109/DASC50938.2020.9256746, 2020,
<https://doi.org/10.1109/DASC50938.2020.9256746>.
[Nitsche_2015]
Nitsche, T., Cordeiro, C., Flores, A. B., Knightly, E. W.,
Perahia, E., and J. C. Widmer, "IEEE 802.11ad: directional
60 GHz communication for multi-Gigabit-per-second Wi-Fi",
IEEE Communications Magazine, vol. 52, no. 12, pp.
132-141, DOI 10.1109/MCOM.2014.6979964, December 2014,
<https://doi.org/10.1109/MCOM.2014.6979964>.
[NSA-EXT] Koutsiamanis, R., Ed., Papadopoulos, G. Z., Montavont, N.,
and P. Thubert, "Common Ancestor Objective Function and
Parent Set DAG Metric Container Extension", Work in
Progress, Internet-Draft, draft-ietf-roll-nsa-extension-
13, 7 July 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-roll-nsa-extension-13>.
[PCE] IETF, "Path Computation Element",
<https://datatracker.ietf.org/doc/charter-ietf-pce/>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>.
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant,
"Deterministic Networking (DetNet) Data Plane: IP over
IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023,
DOI 10.17487/RFC9023, June 2021,
<https://www.rfc-editor.org/info/rfc9023>.
[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>.
[RFC9033] Chang, T., Ed., Vučinić, M., Vilajosana, X., Duquennoy,
S., and D. Dujovne, "6TiSCH Minimal Scheduling Function
(MSF)", RFC 9033, DOI 10.17487/RFC9033, May 2021,
<https://www.rfc-editor.org/info/rfc9033>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
[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>.
[RFC9914] Thubert, P., Ed., Jadhav, R.A., and M. Richardson, "Root-
Initiated Routing State in the Routing Protocol for Low-
Power and Lossy Networks (RPL)", RFC 9914,
DOI 10.17487/RFC9914, April 2026,
<https://www.rfc-editor.org/info/rfc9914>.
[RIH18] Rihacek, C., Haindl, B., Fantappie, P., Pierattelli, S.,
Gräupl, T., Schnell, M., and N. Fistas, "L-band Digital
Aeronautical Communications System (LDACS) Activities in
SESAR2020", 2018 Integrated Communications, Navigation,
Surveillance Conference (ICNS), pp. 4A1-1-4A1-8,
DOI 10.1109/ICNSURV.2018.8384880, April 2018,
<https://doi.org/10.1109/ICNSURV.2018.8384880>.
[RP210854] 3GPP, "Revised WID: Enhanced Industrial Internet of Things
(IoT) and ultra-reliable and low latency communication
(URLLC) support for NR", 3GPP RP-210854, March 2021,
<https://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_91e/Docs/
RP-210854.zip>.
[SAJ14] Haindl, B., Meser, J., Sajatovic, M., Muller, S.,
Arthaber, H., Faseth, T., and M. Zaisberger, "LDACS1
conformance and compatibility assessment", 2014 IEEE/AIAA
33rd Digital Avionics Systems Conference (DASC), pp.
3B3-1-3B3-11, DOI 10.1109/DASC.2014.6979447, October 2014,
<https://doi.org/10.1109/DASC.2014.6979447>.
[SCH08] Schnell, M., Brandes, S., Gligorevic, S., Rokitansky, C.-
H., Ehammer, M., Graeupl, T., Rihacek, C., and M.
Sajatovic, "B-AMC - Broadband Aeronautical Multi-carrier
Communications", 2008 Integrated Communications,
Navigation and Surveillance Conference, pp. 1-12,
DOI 10.1109/ICNSURV.2008.4559173, 2008,
<https://doi.org/10.1109/ICNSURV.2008.4559173>.
[SCH14] Schnell, M., Epple, U., Shutin, D., and N.
Schneckenburger, "LDACS: Future Aeronautical
Communications for Air- Traffic Management", IEEE
Communications Magazine, vol. 52, no. 5, pp. 104-110,
DOI 10.1109/MCOM.2014.6815900, May 2014,
<https://doi.org/10.1109/MCOM.2014.6815900>.
[SCH19] German Aerospace Center (DLR), "DLR tests digital
communications technologies combined with additional
navigation functions for the first time", 27 March 2019,
<https://www.dlr.de/en/latest/
news/2019/01/20190327_modern-technology-for-the-flight-
deck>.
[SP211634] 3GPP, "Study on 5G Timing Resiliency, TSC, and URLLC
enhancements", 3GPP SP-211634, December 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/
TSGS_94E_Electronic_2021_12/Docs/SP-211634.zip>.
[Sudhakaran2021]
Sudhakaran, S., Montgomery, K., Kashef, M., Cavalcanti,
D., and R. Candell, "Wireless Time Sensitive Networking
for Industrial Collaborative Robotic Workcells", 2021 17th
IEEE International Conference on Factory Communication
Systems (WFCS), pp. 91-94,
DOI 10.1109/WFCS46889.2021.9483447, 2021,
<https://ieeexplore.ieee.org/abstract/document/9483447>.
[SYSTOVER5G]
3GPP, "5G System Overview", 8 August 2022,
<https://www.3gpp.org/technologies/5g-system-overview>.
[TiSCH] IETF, "IPv6 over the TSCH mode over 802.15.4e",
<https://datatracker.ietf.org/doc/charter-ietf-6tisch/>.
[TR22804] 3GPP, "Study on Communication for Automation in Vertical
domains (CAV)", 3GPP TS 22.804,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3187>.
[TR2370046]
3GPP, "Study on 5GS Deterministic Networking (DetNet)
interworking", 3GPP TR 23.700-46,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3994>.
[TR37910] 3GPP, "Study on self evaluation towards IMT-2020
submission", 3GPP TR 37.910,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3190>.
[TR38824] 3GPP, "Study on physical layer enhancements for NR ultra-
reliable and low latency case (URLLC)", 3GPP TR 38.824,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3498>.
[TR38825] 3GPP, "Study on NR industrial Internet of Things (IoT)",
3GPP TR 38.825,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3492>.
[TS22104] 3GPP, "Service requirements for cyber-physical control
applications in vertical domains", 3GPP TS 22.104,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3528>.
[TS23501] 3GPP, "System architecture for the 5G System (5GS)",
3GPP TS 23.501,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3144>.
[TS38300] 3GPP, "NR; NR and NG-RAN Overall description; Stage-2",
3GPP TS 38.300,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=3191>.
[TSN5G] 5G-ACIA, "Integration of 5G with Time-Sensitive Networking
for Industrial Communications", 5G-ACIA White Paper,
<https://5g-acia.org/whitepapers/integration-of-5g-with-
time-sensitive-networking-for-industrial-communications>.
[vilajosana21]
Vilajosana, X., Watteyne, T., Chang, T., Vucinic, M.,
Duquennoy, S., and P. Thubert, "IETF 6TiSCH: A Tutorial",
Communications Surveys and Tutorials, IEEE Communications
Society, HAL ID: hal-02420974,
DOI 10.1109/COMST.2019.2939407, December 2019,
<https://inria.hal.science/hal-02420974/file/
IETF_6TiSCH__A_Tutorial__17099609gkvsxdpffdvc_%20(1).pdf>.
[WFA] "Wi-Fi Alliance", <https://www.wi-fi.org>.
[WirelessHART]
FieldComm Group, "WirelessHART",
<https://www.fieldcommgroup.org/technologies/
wirelesshart>.
Many thanks to the participants of the RAW WG, where a lot of the work discussed in this document happened, and to Malcolm Smith for his review of the section on IEEE 802.11. Special thanks for post directorate and IESG reviewers Roman Danyliw, Victoria Pritchard, Donald Eastlake, Mohamed Boucadair, Jiankang Yao, Shivan Kaul Sahib, Mallory Knodel, Ron Bonica, Ketan Talaulikar, Éric Vyncke, and Carlos J. Bernardos.
この文書で議論された多くの作業が行われた RAW WG の参加者、および IEEE 802.11 に関するセクションのレビューを担当した Malcolm Smith に多大な感謝を申し上げます。ポストディレクターおよびIESGの査読者であるRoman Danyliw氏、Victoria Pritchard氏、Donald Eastlake氏、Mohamed Boucadair氏、Jiankang Yao氏、Shivan Kaul Sahib氏、Mallory Knodel氏、Ron Bonica氏、Ketan Talaulikar氏、Éric Vyncke氏、Carlos J. Bernardos氏に心より感謝いたします。
This document aggregates articles from authors specialized in each technology. Beyond the main authors listed on the front page, the following contributors proposed additional text and refinements that improved the document.
このドキュメントは、各テクノロジーに特化した著者による記事を集約したものです。フロントページにリストされている主な著者以外に、次の寄稿者が追加のテキストと文書を改善するための改良を提案しました。
* Georgios Z. Papadopoulos contributed to Section 5 ("IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH)").
* Georgios Z. Papadopoulos はセクション 5 (「IEEE 802.15.4 タイムスロット チャネル ホッピング (TSCH)」) に貢献しました。
* Nils Maeurer and Thomas Graeupl contributed to Section 7 ("L-Band Digital Aeronautical Communications System (LDACS)").
* Nils Maeurer と Thomas Graeupl はセクション 7 (「L バンド デジタル航空通信システム (LDACS)」) に貢献しました。
* Torsten Dudda, Alexey Shapin, and Sara Sandberg contributed to Section 6 ("5G").
* Torsten Dudda、Alexey Shapin、Sara Sandberg はセクション 6 (「5G」) に貢献しました。
* Rocco Di Taranto contributed to Section 4 ("IEEE 802.11").
* Rocco Di Taranto はセクション 4 (「IEEE 802.11」) に貢献しました。
* Rute Sofia contributed to Section 1 ("Introduction") and Section 2 ("Terminology").
* Rute Sofia はセクション 1 (「はじめに」) とセクション 2 (「用語」) に貢献しました。
Pascal Thubert (editor)
Independent
06330 Roquefort-les-Pins
France
Email: pascal.thubert@gmail.com
Dave Cavalcanti
Intel Corporation
2111 NE 25th Ave
Hillsboro, OR 97124
United States of America
Phone: 503 712 5566
Email: dave.cavalcanti@intel.com
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
08018 Barcelona Catalonia
Spain
Email: xvilajosana@uoc.edu
Corinna Schmitt
Research Institute CODE, UniBw M
Werner-Heisenberg-Weg 39
85577 Neubiberg
Germany
Email: corinna.schmitt@unibw.de
Janos Farkas
Ericsson
Budapest
Magyar tudosok korutja 11
1117
Hungary
Email: janos.farkas@ericsson.com