[要約] RFC 8869は、無線ネットワーク上でのインタラクティブなリアルタイムメディアの評価テストケースに関するドキュメントです。このRFCの目的は、異なる無線ネットワーク環境でのリアルタイムメディアのパフォーマンスを評価し、標準化されたテストケースを提供することです。
Internet Engineering Task Force (IETF) Z. Sarker
Request for Comments: 8869 Ericsson AB
Category: Informational X. Zhu
ISSN: 2070-1721 J. Fu
Cisco Systems
January 2021
Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks
無線ネットワーク上の対話型リアルタイムメディアの評価テストケース
Abstract
概要
The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well-functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks.
リアルタイムトランスポートプロトコル（RTP）は、対話型マルチメディア通信アプリケーションのための共通のトランスポート選択です。これらのアプリケーションのパフォーマンスは通常、機能的な輻輳制御アルゴリズムに依存します。シームレスで堅牢なユーザーエクスペリエンスを確保するために、よく設計されたRTPベースの輻輳制御アルゴリズムは、すべてのアクセスネットワークタイプにわたってうまく機能するはずです。この文書では、セルラーネットワークとWi-Fiネットワーク上の候補輻輳制御アルゴリズムの性能を評価するためのテストケースについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8869.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/frfc8869で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Cellular Network Specific Test Cases
2.1. Varying Network Load
2.1.1. Network Connection
2.1.2. Simulation Setup
2.1.3. Expected Behavior
2.2. Bad Radio Coverage
2.2.1. Network Connection
2.2.2. Simulation Setup
2.2.3. Expected Behavior
2.3. Desired Evaluation Metrics for Cellular Test Cases
3. Wi-Fi Networks Specific Test Cases
3.1. Bottleneck in Wired Network
3.1.1. Network Topology
3.1.2. Test/Simulation Setup
3.1.3. Typical Test Scenarios
3.1.4. Expected Behavior
3.2. Bottleneck in Wi-Fi Network
3.2.1. Network Topology
3.2.2. Test/Simulation Setup
3.2.3. Typical Test Scenarios
3.2.4. Expected Behavior
3.3. Other Potential Test Cases
3.3.1. EDCA/WMM usage
3.3.2. Effect of Heterogeneous Link Rates
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Contributors
Acknowledgments
Authors' Addresses
Wireless networks (both cellular and Wi-Fi [IEEE802.11]) are an integral and increasingly more significant part of the Internet. Typical application scenarios for interactive multimedia communication over wireless include video conferencing calls in a bus or train as well as live media streaming at home. It is well known that the characteristics and technical challenges for supporting multimedia services over wireless are very different from those of providing the same service over a wired network. Although the basic test cases as defined in [RFC8867] have covered many common effects of network impairments for evaluating RTP-based congestion control schemes, they remain to be tested over characteristics and dynamics unique to a given wireless environment. For example, in cellular networks, the base station maintains individual queues per radio bearer per user hence it leads to a different nature of interactions between traffic flows of different users. This contrasts with a typical wired network setting where traffic flows from all users share the same queue at the bottleneck. Furthermore, user mobility patterns in a cellular network differ from those in a Wi-Fi network. Therefore, it is important to evaluate the performance of proposed candidate RTP-based congestion control solutions over cellular mobile networks and over Wi-Fi networks respectively.
無線ネットワーク（セルラーとWi-Fi [IEEE802.11]の両方）は、インターネットの不可欠でますます重要な部分です。ワイヤレスを介した対話型マルチメディア通信のための典型的なアプリケーションシナリオには、バスまたは電車の中のビデオ会議呼び出し、ならびに家庭でのライブメディアが含まれています。ワイヤレスでマルチメディアサービスをサポートするための特性と技術的な課題は、有線ネットワークを介して同じサービスを提供するものとは非常に異なることがよく知られています。 [RFC8867]で定義されている基本的なテストケースは、RTPベースの輻輳制御方式を評価するためのネットワーク障害の多くの一般的な影響をカバーしていますが、特定のワイヤレス環境に固有の特性やダイナミクスを超えてテストされています。例えば、セルラネットワークでは、基地局はユーザごとに無線ベアラあたり個々の待ち行列を維持しているので、異なるユーザのトラフィックフロー間の相互作用の異なる性質をもたらす。これは、すべてのユーザーからのトラフィックがボトルネックで同じキューを共有する典型的な有線ネットワーク設定と対照的です。さらに、セルラネットワーク内のユーザモビリティパターンは、Wi - Fiネットワーク内のものとは異なる。したがって、それぞれセルラーモバイルネットワーク上およびWi-Fiネットワークを介した候補RTPベースの輻輳制御ソリューションのパフォーマンスをそれぞれ評価することが重要です。
[RFC8868] provides guidelines for evaluating candidate algorithms and recognizes the importance of testing over wireless access networks. However, it does not describe any specific test cases for performance evaluation of candidate algorithms. This document describes test cases specifically targeting cellular and Wi-Fi networks.
[RFC8868]候補アルゴリズムを評価するためのガイドラインを提供し、無線アクセスネットワークを介したテストの重要性を認識しています。ただし、候補アルゴリズムの性能評価のための具体的なテストケースは記述されていません。この文書では、セルラーネットワークとWi-Fiネットワークを特別にターゲティングするテストケースについて説明します。
A cellular environment is more complicated than its wireline counterpart since it seeks to provide services in the context of variable available bandwidth, location dependencies, and user mobilities at different speeds. In a cellular network, the user may reach the cell edge, which may lead to a significant number of retransmissions to deliver the data from the base station to the destination and vice versa. These radio links will often act as a bottleneck for the rest of the network and will eventually lead to excessive delays or packet drops. An efficient retransmission or link adaptation mechanism can reduce the packet loss probability, but some packet losses and delay variations will remain. Moreover, with increased cell load or handover to a congested cell, congestion in the transport network will become even worse. Besides, there exist certain characteristics that distinguish the cellular network from other wireless access networks such as Wi-Fi. In a cellular network:
セルラー環境は、可変使用可能な帯域幅、位置依存関係、および異なる速度でのユーザーの移動可能さのコンテキストでサービスを提供しようとしているので、その有線の対応者よりも複雑です。セルラネットワークでは、ユーザはセルエッジに到達することができ、これは基地局から宛先へのデータを配信するためにかなりの数の再送信をもたらし、その逆もまた同様である。これらの無線リンクは、しばしばネットワークの残りの部分のためのボトルネックとして機能し、最終的には過度の遅延またはパケットの降下をもたらすでしょう。効率的な再送またはリンク適応メカニズムは、パケット損失確率を低下させる可能性があるが、いくつかのパケット損失および遅延変動は残る。さらに、細胞荷重や混雑セルへのハンドオーバが増えて、トランスポートネットワーク内の輻輳はさらに悪化します。また、セルラーネットワークをWi-Fiなどの他のワイヤレスアクセスネットワークと区別する特定の特性が存在します。セルラーネットワークで：
* The bottleneck is often a shared link with relatively few users.
* ボトルネックはしばしば比較的少ないユーザーと共有リンクです。
- The cost per bit over the shared link varies over time and is different for different users.
- 共有リンクの上のビットあたりのコストは時間の経過とともに変化し、ユーザーが異なります。
- Leftover/unused resources can be consumed by other greedy users.
- 残りの/未使用のリソースは他の貪欲なユーザーによって消費される可能性があります。
* Queues are always per radio bearer, hence each user can have many such queues.
* キューは常に無線ベアラごとに、したがって各ユーザーにはそのようなキューが多数あります。
* Users can experience both inter- and intra-Radio Access Technology (RAT) handovers (see [HO-def-3GPP] for the definition of "handover").
* ユーザーは、無線アクセス技術（RAT）の両方のハンドオーバを経験することができます（「ハンドオーバ」の定義については、[HO-DEF-3GPP]を参照）。
* Handover between cells or change of serving cells (as described in [HO-LTE-3GPP] and [HO-UMTS-3GPP]) might cause user plane interruptions, which can lead to bursts of packet losses, delay, and/or jitter. The exact behavior depends on the type of radio bearer. Typically, the default best-effort bearers do not generate packet loss, instead, packets are queued up and transmitted once the handover is completed.
* セル間のハンドオーバまたはサービングセルの変更（[HO-LTE-3GPP]および[HO-UMTS-3GPP]に記載されているように）は、ユーザープレーンの中断を引き起こす可能性があり、パケット損失、遅延、および/またはジッタのバーストにつながる可能性があります。正確な動作は無線ベアラの種類によって異なります。通常、デフォルトのベストエフォートベアラはパケット損失を生成しません。代わりに、ハンドオーバが完了するとパケットがキューに入れられて送信されます。
* The network part decides how much the user can transmit.
* ネットワーク部は、ユーザーがどのくらい送信できるかを決定します。
* The cellular network has variable link capacity per user.
* セルラーネットワークは、ユーザーごとに可変リンク容量を持ちます。
- It can vary as fast as a period of milliseconds.
- それはミリ秒の期間と同じくらい速く異なることがあります。
- It depends on many factors (such as distance, speed, interference, different flows).
- それは多くの要因（距離、速度、干渉、さまざまなフローなど）によって異なります。
- It uses complex and smart link adaptation, which makes the link behavior ever more dynamic.
- 複雑でスマートなリンクの適応を使用します。これはリンク動作をより動的にします。
- The scheduling priority depends on the estimated throughput.
- スケジューリングの優先順位は推定スループットに依存します。
* Both Quality of Service (QoS) and non-QoS radio bearers can be used.
* サービス品質（QoS）および非QoS無線ベアラの両方を使用することができる。
Hence, a real-time communication application operating over a cellular network needs to cope with a shared bottleneck link and variable link capacity, events like handover, non-congestion-related loss, and abrupt changes in bandwidth (both short term and long term) due to handover, network load, and bad radio coverage. Even though 3GPP has defined QoS bearers [QoS-3GPP] to ensure high-quality user experience, it is still preferable for real-time applications to behave in an adaptive manner.
したがって、セルラーネットワークを介して動作するリアルタイム通信アプリケーションは、共有ボトルネックリンクと可変リンク容量、ハンドオーバ、非輻輳関連損失などのイベント、および帯域幅の急激な変化に対処する必要があります（短期と長期的なもの）。ハンドオーバ、ネットワーク負荷、および無線カバレッジのために。3GPPがQoSベアラ[QoS-3GPP]を定義したとしても、高品質のユーザーエクスペリエンスを確保するためには、リアルタイムアプリケーションが適応的な方法で動作することがまだ好ましいです。
Different mobile operators deploy their own cellular networks with their own set of network functionalities and policies. Usually, a mobile operator network includes a range of radio access technologies such as 3G and 4G/LTE. Looking at the specifications of such radio technologies, it is evident that only the more recent radio technologies can support the high bandwidth requirements from real-time interactive video applications. Future real-time interactive applications will impose even greater demand on cellular network performance, which makes 4G (and beyond) radio technologies more suitable for such genre of application.
異なるモバイルオペレータは、独自のネットワーク機能とポリシーの独自のセットを使用して独自のセルラネットワークを展開します。通常、モバイルオペレータネットワークは、3Gと4G / LTEなどの無線アクセス技術の範囲を含む。そのような無線技術の仕様を見ると、最近の無線技術のみがリアルタイムの対話型ビデオアプリケーションからの高い帯域幅要件をサポートできることは明らかです。将来のリアルタイム対話型アプリケーションは、セルラネットワーク性能に対する需要がさらに大きな課金され、それはそのようなジャンルのアプリケーションに適した4G（そしてそれ以上）無線技術をより適切にする。
The key factors in defining test cases for cellular networks are:
セルラーネットワークのテストケースを定義する際の重要な要素は次のとおりです。
* Shared and varying link capacity
* 共有とさまざまなリンク容量
* Mobility
* 可動性
* Handover
* 引き渡す
However, these factors are typically highly correlated in a cellular network. Therefore, instead of devising separate test cases for individual important events, we have divided the test cases into two categories. It should be noted that the goal of the following test cases is to evaluate the performance of candidate algorithms over the radio interface of the cellular network. Hence, it is assumed that the radio interface is the bottleneck link between the communicating peers and that the core network does not introduce any extra congestion along the path. Consequently, this document has left out of scope the combination of multiple access technologies involving both cellular and Wi-Fi users. In this latter case, the shared bottleneck is likely at the wired backhaul link. These test cases further assume a typical real-time telephony scenario where one real-time session consists of one voice stream and one video stream.
しかしながら、これらの要因は典型的にはセルラネットワークにおいて高度に相関している。したがって、個々の重要なイベントの個別のテストケースを考案する代わりに、テストケースを2つのカテゴリに分割しました。なお、以下のテストケースの目的は、セルラーネットワークの無線インタフェースを介した候補アルゴリズムの性能を評価することであることに留意されたい。したがって、無線インタフェースは、通信ピア間のボトルネックリンクであり、コアネットワークがその経路に沿って余分な輻輳を導入しないと仮定される。その結果、この文書は、セルラーユーザーとWi-Fiユーザーの両方を含む複数のアクセス技術の組み合わせを省略しています。この後者の場合、共有ボトルネックは有線バックホールリンクである可能性があります。これらのテストケースはさらに、1つのリアルタイムセッションが1つの音声ストリームと1つのビデオストリームで構成されている典型的なリアルタイムテレフォニーシナリオを想定しています。
Even though it is possible to carry out tests over operational cellular networks (e.g., LTE/5G), and actually such tests are already available today, these tests cannot in general be carried out in a deterministic fashion to ensure repeatability. The main reason is that these networks are controlled by cellular operators, and there exists various amounts of competing traffic in the same cell(s). In practice, it is only in underground mines that one can carry out near deterministic testing. Even there, it is not guaranteed either as workers in the mines may carry with them their personal mobile phones. Furthermore, the underground mining setting may not reflect typical usage patterns in an urban setting. We, therefore, recommend that a cellular network simulator be used for the test cases defined in this document, for example -- the LTE simulator in [NS-3].
操作セルラネットワーク（例えば、LTE / 5G）を介してテストを実行することが可能であっても、実際にはそのようなテストはすでに入手可能であるが、一般に再現性を確実にするために決定的な方法で実行することができない。主な理由は、これらのネットワークがセルラ演算子によって制御され、同じセル内に様々な競合するトラフィックが存在することです。実際には、それは地下鉱山が決定論的テスト近くに実行できることがあります。そこでも、鉱山の労働者が彼らの個人的な携帯電話を運ぶことができるので保証されていません。さらに、地下採掘設定は、都市設定における一般的な使用模様を反映していない可能性があります。したがって、この文書で定義されているテストケースには、セルラーネットワークシミュレータを使用することをお勧めします。たとえば、[NS-3]のLTEシミュレータ。
The goal of this test is to evaluate the performance of the candidate congestion control algorithm under varying network load. The network load variation is created by adding and removing network users, a.k.a. User Equipment (UE), during the simulation. In this test case, each user/UE in the media session is an endpoint following RTP-based congestion control. User arrivals follow a Poisson distribution proportional to the length of the call, to keep the number of users per cell fairly constant during the evaluation period. At the beginning of the simulation, there should be enough time to warm up the network. This is to avoid running the evaluation in an empty network where network nodes have empty buffers and low interference at the beginning of the simulation. This network initialization period should be excluded from the evaluation period. Typically, the evaluation period starts 30 seconds after test initialization.
このテストの目的は、さまざまなネットワーク負荷の下で候補輻輳制御アルゴリズムの性能を評価することです。ネットワーク負荷変動は、シミュレーション中にネットワークユーザ、A.K.A.ユーザ機器（UE）を追加および削除することによって作成される。このテストケースでは、メディアセッション内の各ユーザー/ UEは、RTPベースの輻輳制御の後のエンドポイントです。ユーザーの到着は、評価期間中にセルごとにユーザー数をかなり一定に保つために、通話の長さに比例したポアソン分布に従います。シミュレーションの開始時には、ネットワークをウォームアップするのに十分な時間があるはずです。これは、ネットワークノードが空のバッファとシミュレーションの開始時に低い干渉を持つ空のネットワークで評価を実行しないようにするためです。このネットワーク初期化期間は評価期間から除外されるべきです。通常、評価期間はテスト初期化後30秒後に開始されます。
This test case also includes user mobility and some competing traffic. The latter includes both the same types of flows (with same adaptation algorithms) and different types of flows (with different services and congestion control schemes).
このテストケースには、ユーザーのモビリティと競合するトラフィックも含まれます。後者は、同じタイプのフロー（同じ適応アルゴリズムを持つ）と異なる種類のフロー（さまざまなサービスおよび輻輳制御方式を持つ）の両方を含む。
Each mobile user is connected to a fixed user. The connection between the mobile user and fixed user consists of a cellular radio access, an Evolved Packet Core (EPC), and an Internet connection. The mobile user is connected to the EPC using cellular radio access technology, which is further connected to the Internet. At the other end, the fixed user is connected to the Internet via a wired connection with sufficiently high bandwidth, for instance, 10 Gbps, so that the system bottleneck is on the cellular radio access interface. The wired connection in this setup does not introduce any network impairments to the test; it only adds 10 ms of one-way propagation delay.
各モバイルユーザは固定ユーザに接続されている。モバイルユーザと固定ユーザとの間の接続は、セルラ無線アクセス、進化したパケットコア（EPC）、およびインターネット接続で構成されている。モバイルユーザは、インターネットにさらに接続されているセルラ無線アクセス技術を使用してEPCに接続されている。もう一方の端で、固定ユーザーは、システムのボトルネックがセルラ無線アクセスインターフェース上にあるように、十分に高い帯域幅、たとえば10 Gbpsで有線接続を介してインターネットに接続されています。このセットアップの有線接続は、テストにネットワーク障害を紹介しません。それは一方向の伝播遅延の10 msのみを追加します。
The path from the fixed user to the mobile users is defined as "downlink", and the path from the mobile users to the fixed user is defined as "uplink". We assume that only uplink or downlink is congested for mobile users. Hence, we recommend that the uplink and downlink simulations are run separately.
固定ユーザからモバイルユーザへのパスは「ダウンリンク」として定義され、モバイルユーザから固定ユーザへのパスは「アップリンク」として定義される。Mobileユーザーには、アップリンクまたはダウンリンクのみが輻輳しているとします。したがって、アップリンクシミュレーションとダウンリンクシミュレーションが別々に実行されることをお勧めします。
uplink
++))) +-------------------------->
++-+ ((o))
| | / \ +-------+ +------+ +---+
+--+ / \----+ +-----+ +----+ |
/ \ +-------+ +------+ +---+
UE BS EPC Internet fixed
<--------------------------+
downlink
Figure 1: Simulation Topology
図1：シミュレーショントポロジー
The values enclosed within "[ ]" for the following simulation attributes follow the same notion as in [RFC8867]. The desired simulation setup is as follows:
以下のシミュレーション属性の場合、 "[]"内に囲まれた値は、[RFC8867]と同じ概念に従います。希望のシミュレーション設定は次のとおりです。
Radio environment:
無線環境：
Deployment and propagation model: 3GPP case 1 (see [HO-deploy-3GPP])
展開と伝播モデル：3GPPケース1（[HO-Deploy-3GPP]参照）
Antenna: Multiple-Input and Multiple-Output (MIMO), 2D or 3D antenna pattern
アンテナ：多入力と多出力（MIMO）、2Dまたは3Dアンテナパターン
Mobility: [3 km/h, 30 km/h]
Transmission bandwidth: 10 MHz
伝送帯域幅：10 MHz
Number of cells: multi-cell deployment (3 cells per Base Station (BS) * 7 BS) = 21 cells
セル数：マルチセル展開（基地局（BS）* 7 BS）= 21セル
Cell radius: 166.666 meters
セル半径：166.666メートル
Scheduler: Proportional fair with no priority
スケジューラ：優先順位のないものに比例します
Bearer: Default bearer for all traffic
ベアラ：すべてのトラフィックのデフォルトのベアラ
Active Queue Management (AQM) settings: AQM [on, off]
アクティブキュー管理（AQM）設定：AQM [ON、OFF]
End-to-end Round Trip Time (RTT): [40 ms, 150 ms]
終わりの終わりの往復時間（RTT）：[40ミリ秒、150ミリ秒]
User arrival model: Poisson arrival model
ユーザー到着モデル：ポアソン到着モデル
User intensity:
ユーザー強度：
Downlink user intensity: {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0, 7.7, 8.4, 9,1, 9.8, 10.5}
ダウンリンクのユーザー強度：{0.7,1.4,2.1,2.8,3.5,4.2,4.9,5.6,6.3,7.0,7.7,8.4,9,1,9.8,10.5}
Uplink user intensity: {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0}
アップリンクのユーザー強度：{0.7,1.4,2.1,2.8,3.5,4.2,4.9,5.6,6.3,7.0}
Simulation duration: 91 s
シミュレーション期間：91 S.
Evaluation period: 30 s - 60 s
評価期間：30秒 - 60 S
Media traffic:
メディアトラフィック：
Media type: Video
メディアタイプ：ビデオ
Media direction: [uplink, downlink]
メディアの方向：[アップリンク、ダウンリンク]
Number of media sources per user: One (1)
1ユーザーあたりのメディアソース数：1（1）
Media duration per user: 30 s
ユーザーごとのメディア期間：30 S
Media source: same as defined in Section 4.3 of [RFC8867]
メディアソース：[RFC8867]のセクション4.3で定義されているのと同じ
Media type: Audio
メディアタイプ：オーディオ
Media direction: [uplink, downlink]
メディアの方向：[アップリンク、ダウンリンク]
Number of media sources per user: One (1)
1ユーザーあたりのメディアソース数：1（1）
Media duration per user: 30 s
ユーザーごとのメディア期間：30 S
Media codec: Constant Bit Rate (CBR)
メディアコーデック：一定ビットレート（CBR）
Media bitrate: 20 Kbps
メディアビットレート：20 kbps
Adaptation: off
適応：オフ
Other traffic models:
他のトラフィックモデル：
Downlink simulation: Maximum of 4 Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681])
ダウンリンクシミュレーション：最大4 Mbps /セル（デフォルトのTCP輻輳制御の後のWebブラウジングまたはFTPトラフィック[RFC5681]）
Uplink simulation: Maximum of 2 Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681])
アップリンクシミュレーション：最大2 Mbps / Cell（デフォルトのTCP輻輳制御後のWebブラウジングまたはFTPトラフィック[RFC5681]）
The investigated congestion control algorithms should result in maximum possible network utilization and stability in terms of rate variations, lowest possible end-to-end frame latency, network latency, and Packet Loss Rate (PLR) at different cell load levels.
調査された輻輳制御アルゴリズムは、さまざまなセル負荷レベルで、レートバリエーション、可能な限り低いエンドツーエンドフレームレイテンシ、ネットワークレイテンシ、およびパケット損失率（PLR）の点で最大のネットワーク使用率と安定性をもたらすはずです。
The goal of this test is to evaluate the performance of the candidate congestion control algorithm when users visit part of the network with bad radio coverage. The scenario is created by using a larger cell radius than that in the previous test case. In this test case, each user/UE in the media session is an endpoint following RTP-based congestion control. User arrivals follow a Poisson distribution proportional to the length of the call, to keep the number of users per cell fairly constant during the evaluation period. At the beginning of the simulation, there should be enough time to warm up the network. This is to avoid running the evaluation in an empty network where network nodes have empty buffers and low interference at the beginning of the simulation. This network initialization period should be excluded from the evaluation period. Typically, the evaluation period starts 30 seconds after test initialization.
このテストの目的は、ユーザーが不良無線カバレッジでネットワークの一部を訪問するときの候補輻輳制御アルゴリズムのパフォーマンスを評価することです。シナリオは、前のテストケース以外のセル半径を使用して作成されます。このテストケースでは、メディアセッション内の各ユーザー/ UEは、RTPベースの輻輳制御の後のエンドポイントです。ユーザーの到着は、評価期間中にセルごとにユーザー数をかなり一定に保つために、通話の長さに比例したポアソン分布に従います。シミュレーションの開始時には、ネットワークをウォームアップするのに十分な時間があるはずです。これは、ネットワークノードが空のバッファとシミュレーションの開始時に低い干渉を持つ空のネットワークで評価を実行しないようにするためです。このネットワーク初期化期間は評価期間から除外されるべきです。通常、評価期間はテスト初期化後30秒後に開始されます。
This test case also includes user mobility and some competing traffic. The latter includes the same kind of flows (with same adaptation algorithms).
このテストケースには、ユーザーのモビリティと競合するトラフィックも含まれます。後者は同じ種類の流れ（同じ適応アルゴリズムを有する）を含む。
Same as defined in Section 2.1.1.
セクション2.1.1で定義されていると同じです。
The desired simulation setup is the same as the Varying Network Load test case defined in Section 2.1 except for the following changes:
希望のシミュレーション設定は、以下の変更点を除いて、セクション2.1で定義されているさまざまなネットワーク負荷テストケースと同じです。
Radio environment: Same as defined in Section 2.1.2 except for the following:
無線環境：2.1.2項で定義されていると同じです。
Deployment and propagation model: 3GPP case 3 (see [HO-deploy-3GPP])
展開と伝播モデル：3GPPケース3（[HO-Deploy-3GPP]参照）
Cell radius: 577.3333 meters
セル半径：577.3333メートル
Mobility: 3 km/h
モビリティ：3 km / h
User intensity: {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0}
Media traffic model: Same as defined in Section 2.1.2
メディアトラフィックモデル：2.1.2項で定義したものと同じ
Other traffic models:
他のトラフィックモデル：
Downlink simulation: Maximum of 2 Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681])
ダウンリンクシミュレーション：最大2 Mbps / Cell（デフォルトのTCP輻輳制御のデフォルトのWebブラウジングまたはFTPトラフィック[RFC5681]）
Uplink simulation: Maximum of 1 Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681])
アップリンクシミュレーション：最大1 Mbps /セル（デフォルトのWebブラウジングまたはFTPトラフィックのデフォルトのTCP輻輳制御[RFC5681]）
The investigated congestion control algorithms should result in maximum possible network utilization and stability in terms of rate variations, lowest possible end-to-end frame latency, network latency, and Packet Loss Rate (PLR) at different cell load levels.
調査された輻輳制御アルゴリズムは、さまざまなセル負荷レベルで、レートバリエーション、可能な限り低いエンドツーエンドフレームレイテンシ、ネットワークレイテンシ、およびパケット損失率（PLR）の点で最大のネットワーク使用率と安定性をもたらすはずです。
The evaluation criteria document [RFC8868] defines the metrics to be used to evaluate candidate algorithms. Considering the nature and distinction of cellular networks, we recommend that at least the following metrics be used to evaluate the performance of the candidate algorithms:
評価基準文書[RFC8868]は、候補アルゴリズムを評価するために使用されるメトリックを定義します。セルラーネットワークの性質と区別を考慮すると、少なくとも次のメトリックを使用して候補アルゴリズムの性能を評価することをお勧めします。
* Average cell throughput (for all cells), shows cell utilization.
* 平均セルスループット（全セルの場合）は、セルの使用率を示します。
* Application sending and receiving bitrate, goodput.
* アプリケーション送受信ビットレート、グッドプット。
* Packet Loss Rate (PLR).
* パケット損失率（PLR）。
* End-to-end media frame delay. For video, this means the delay from capture to display.
* エンドツーエンドメディアフレーム遅延。ビデオの場合、これはキャプチャから表示までの遅延を意味します。
* Transport delay.
* 輸送遅延
* Algorithm stability in terms of rate variation.
* レート変動の観点からのアルゴリズムの安定性
Given the prevalence of Internet access links over Wi-Fi, it is important to evaluate candidate RTP-based congestion control solutions over test cases that include Wi-Fi access links. Such evaluations should highlight the inherently different characteristics of Wi-Fi networks in contrast to their wired counterparts:
Wi-Fiを介したインターネットアクセスリンクの有病率を考えると、Wi-Fiアクセスリンクを含むテストケースにわたる候補RTPベースの輻輳制御ソリューションを評価することが重要です。そのような評価は、有線のカウンターパートとは対照的に、Wi-Fiネットワークの本質的に異なる特性を強調しているはずです。
* The wireless radio channel is subject to interference from nearby transmitters, multipath fading, and shadowing. These effects lead to fluctuations in the link throughput and sometimes an error-prone communication environment.
* 無線無線チャネルは、近くの送信機、マルチパスフェージング、およびシャドウイングからの干渉を受ける。これらの効果は、リンクスループットの変動、時にはエラーが発生しやすい通信環境につながります。
* Available network bandwidth is not only shared over the air between concurrent users but also between uplink and downlink traffic due to the half-duplex nature of the wireless transmission medium.
* 利用可能なネットワーク帯域幅は、同時ユーザ間でなく、無線伝送媒体の半二重の性質のためにアップリンクとダウンリンクトラフィックとの間でも共有されるだけではない。
* Packet transmissions over Wi-Fi are susceptible to contentions and collisions over the air. Consequently, traffic load beyond a certain utilization level over a Wi-Fi network can introduce frequent collisions over the air and significant network overhead, as well as packet drops due to buffer overflow at the transmitters. This, in turn, leads to excessive delay, retransmissions, packet losses, and lower effective bandwidth for applications. Note further that the collision-induced delay and loss patterns are qualitatively different from those caused by congestion over a wired connection.
* Wi-Fiを介したパケット送信は、空気の上での議論や衝突の影響を受けやすくなります。その結果、Wi-Fiネットワーク上の特定の利用レベルを超えるトラフィック負荷は、送信機でのバッファオーバーフローによるパケットドロップを介して頻繁に衝突し、大幅なネットワークオーバーヘッドを介して頻繁に衝突します。これにより、アプリケーションのための過度の遅延、再送信、パケット損失、およびより低い有効帯域幅をもたらします。さらに、衝突誘発遅延パターンが、有線接続に対する輻輳によって引き起こされるものとは定性的に異なることに注意してください。
* The IEEE 802.11 standard (i.e., Wi-Fi) supports multi-rate transmission capabilities by dynamically choosing the most appropriate modulation and coding scheme (MCS) for the given received signal strength. A different choice in the MCS Index leads to different physical-layer (PHY-layer) link rates and consequently different application-layer throughput.
* IEEE802.11規格（すなわち、Wi - Fi）は、所与の受信信号強度について最も適切な変調および符号化方式（MCS）を動的に選択することによってマルチレート伝送能力をサポートする。MCSインデックスの異なる選択は、異なる物理層（PHY層）リンクレート、その結果として異なるアプリケーション層スループットをもたらす。
* The presence of legacy devices (e.g., ones operating only in IEEE 802.11b) at a much lower PHY-layer link rate can significantly slow down the rest of a modern Wi-Fi network. As discussed in [Heusse2003], the main reason for such anomaly is that it takes much longer to transmit the same packet over a slower link than over a faster link, thereby consuming a substantial portion of air time.
* 従来のデバイスの存在（例えば、IEEE 802.11bでのみ動作する）は、はるかに低いPHYレイヤーリンクレートで、最新のWi-Fiネットワークの残りを大幅に遅くすることができます。[HEUSSE2003]で説明したように、そのような異常の主な理由は、それがより速いリンクよりも遅いリンクを介して同じパケットを送信するのがずっと時間がかかり、それによって空気時間のかなりの部分を消費することです。
* Handover from one Wi-Fi Access Point (AP) to another may lead to excessive packet delays and losses during the process.
* あるWi - Fiアクセスポイント（AP）から別のWi-Fiアクセスポイント（AP）へのハンドオーバは、プロセス中の過度のパケット遅延および損失を引き起こす可能性があります。
* IEEE 802.11e has introduced the Enhanced Distributed Channel Access (EDCA) mechanism to allow different traffic categories to contend for channel access using different random back-off parameters. This mechanism is a mandatory requirement for the Wi-Fi Multimedia (WMM) certification in Wi-Fi Alliance. It allows for prioritization of real-time application traffic such as voice and video over non-urgent data transmissions (e.g., file transfer).
* IEEE 802.11eは、異なるランダムバックオフパラメータを使用して異なるトラフィックカテゴリをチャネルアクセスに競合させることを可能にするために拡張分散チャネルアクセス（EDCA）メカニズムを導入しました。このメカニズムは、Wi-FiアライアンスにおけるWi-Fiマルチメディア（WMM）認証の必須要件です。これは、非緊急データ送信（例えば、ファイル転送）を介して音声やビデオなどのリアルタイムアプリケーショントラフィックの優先順位付けを可能にします。
In summary, the presence of Wi-Fi access links in different network topologies can exert different impacts on the network performance in terms of application-layer effective throughput, packet loss rate, and packet delivery delay. These, in turn, will influence the behavior of end-to-end real-time multimedia congestion control.
要約すると、異なるネットワークトポロジにおけるWi-Fiアクセスリンクの存在は、アプリケーション層の有効なスループット、パケット損失率、およびパケット配信遅延に関して、ネットワーク性能に異なる影響を及ぼします。これらは、順番に、エンドツーエンドのリアルタイムマルチメディア輻輳制御の動作に影響を与えます。
Unless otherwise mentioned, the test cases in this section choose the PHY- and MAC-layer parameters based on the IEEE 802.11n standard. Statistics collected from enterprise Wi-Fi networks show that the two dominant physical modes are 802.11n and 802.11ac, accounting for 41% and 58% of connected devices, respectively. As Wi-Fi standards evolve over time -- for instance, with the introduction of the emerging Wi-Fi 6 (based on IEEE 802.11ax) products -- the PHY- and MAC-layer test case specifications need to be updated accordingly to reflect such changes.
Typically, a Wi-Fi access network connects to a wired infrastructure. Either the wired or the Wi-Fi segment of the network can be the bottleneck. The following sections describe basic test cases for both scenarios separately. The same set of performance metrics as in [RFC8867]) should be collected for each test case.
通常、Wi-Fiアクセスネットワークは有線インフラストラクチャに接続します。ネットワークの有線またはWi-Fiセグメントのどちらかがボトルネックになる可能性があります。次のセクションでは、両方のシナリオの基本テストケースが別々に説明します。テストケースごとに、[RFC8867]と同じパフォーマンスメトリックセットを収集する必要があります。
We recommend carrying out the test cases as defined in this document using a simulator, such as [NS-2] or [NS-3]. When feasible, it is encouraged to perform testbed-based evaluations using Wi-Fi access points and endpoints running up-to-date IEEE 802.11 protocols, such as 802.11ac and the emerging Wi-Fi 6, so as to verify the viability of the candidate schemes.
[NS-2]または[NS-3]などのシミュレータを使用して、この文書で定義されているテストケースを実行することをお勧めします。実行可能であれば、802.11acや新興Wi-Fi 6などの最新のIEEE 802.11プロトコルを実行しているWi-Fiアクセスポイントとエンドポイントを使用してテストベースに基づく評価を実行することが奨励されています。候補スキーム
The test scenarios below are intended to mimic the setup of video conferencing over Wi-Fi connections from the home. Typically, the Wi-Fi home network is not congested, and the bottleneck is present over the wired home access link. Although it is expected that test evaluation results from this section are similar to those in [RFC8867], it is still worthwhile to run through these tests as sanity checks.
以下のテストシナリオは、ホームからのWi-Fi接続を介したビデオ会議のセットアップを模倣することを目的としています。通常、Wi-Fiホームネットワークは輻輳しておらず、ボトルネックは有線ホームアクセスリンクの上に存在します。このセクションのテスト評価結果は[RFC8867]のテスト評価結果と同様であると予想されますが、特性チェックとしてこれらのテストを実行することは依然として価値があります。
Figure 2 shows the network topology of Wi-Fi test cases. The test contains multiple mobile nodes (MNs) connected to a common Wi-Fi AP and their corresponding wired clients on fixed nodes (FNs). Each connection carries either an RTP-based media flow or a TCP traffic flow. Directions of the flows can be uplink (i.e., from mobile nodes to fixed nodes), downlink (i.e., from fixed nodes to mobile nodes), or bidirectional. The total number of uplink/downlink/bidirectional flows for RTP-based media traffic and TCP traffic are denoted as N and M, respectively.
図2は、Wi-Fiテストケースのネットワークトポロジを示しています。このテストには、共通のWi-Fi APに接続された複数のモバイルノード（MNS）と、固定ノード（FNS）上の対応する有線クライアントが含まれています。各接続は、RTPベースのメディアフローまたはTCPトラフィックフローのいずれかを担います。フローの方向はアップリンク（すなわち、モバイルノードから固定ノードへ）、ダウンリンク（すなわち、固定ノードからモバイルノードへ）、または双方向にある。RTPベースのメディアトラフィックおよびTCPトラフィックのアップリンク/ダウンリンク/双方向フローの総数は、それぞれNおよびMとして表されます。
Uplink
+----------------->+
+------+ +------+
| MN_1 |)))) /=====| FN_1 |
+------+ )) // +------+
. )) // .
. )) // .
. )) // .
+------+ +----+ +-----+ +------+
| MN_N | ))))))) | | | |========| FN_N |
+------+ | | | | +------+
| AP |=========| FN0 |
+----------+ | | | | +----------+
| MN_tcp_1 | )))) | | | |======| FN_tcp_1 |
+----------+ +----+ +-----+ +----------+
. )) \\ .
. )) \\ .
. )) \\ .
+----------+ )) \\ +----------+
| MN_tcp_M |))) \=====| FN_tcp_M |
+----------+ +----------+
+<-----------------+
Downlink
Figure 2: Network Topology for Wi-Fi Test Cases
図2：Wi-Fiテストケースのネットワークトポロジ
Test duration: 120 s
テスト期間：120 S.
Wi-Fi network characteristics:
Wi-Fiネットワークの特徴：
Radio propagation model: Log-distance path loss propagation model (see [NS3WiFi])
ラジオ伝搬モデル：ログ距離パス損失伝搬モデル（[NS3WiFi]を参照）
PHY- and MAC-layer configuration: IEEE 802.11n
PHY-およびMAC層の構成：IEEE 802.11n
MCS Index at 11: Raw data rate at 52 Mbps, 16-QAM (Quadrature amplitude modulation) and 1/2 coding rate
52Mbps、16 - QAM（直交振幅変調）および1/2符号化率でのRAWデータレートでのMCSインデックス
Wired path characteristics:
有線道の特徴：
Path capacity: 1 Mbps
パス容量：1 Mbps
One-way propagation delay: 50 ms
一方向伝搬遅延：50ミリ秒
Maximum end-to-end jitter: 30 ms
最大エンドツーエンドジッタ：30ミリ秒
Bottleneck queue type: Drop tail
ボトルネックキュータイプ：ドロップテール
Bottleneck queue size: 300 ms
ボトルネックキューサイズ：300ミリ秒
Path loss ratio: 0%
Application characteristics:
アプリケーションの特性：
Media traffic:
メディアトラフィック：
Media type: Video
メディアタイプ：ビデオ
Media direction: See Section 3.1.3
メディアの方向：セクション3.1.3を参照してください
Number of media sources (N): See Section 3.1.3
メディアソース数（N）：セクション3.1.3を参照してください。
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 119 s
終了時間：119 S
Competing traffic:
競合するトラフィック：
Type of sources: Long-lived TCP or CBR over UDP
ソースの種類：UDP上の長寿命のTCPまたはCBR
Traffic direction: See Section 3.1.3
交通方向：セクション3.1.3を参照してください
Number of sources (M): See Section 3.1.3
ソース数（m）：セクション3.1.3を参照してください。
Congestion control: Default TCP congestion control [RFC5681] or CBR traffic over UDP
輻輳制御：UDP上のデフォルトのTCP輻輳制御[RFC5681]またはCBRトラフィック
Traffic timeline: See Section 3.1.3
トラフィックタイムライン：セクション3.1.3を参照してください
Single uplink RTP-based media flow: N=1 with uplink direction and M=0.
単一アップリンクRTPベースのメディアフロー：N = 1、アップリンク方向、M = 0。
One pair of bidirectional RTP-based media flows: N=2 (i.e., one uplink flow and one downlink flow); M=0.
一対の双方向RTPベースのメディアフロー：n = 2（すなわち、1つのアップリンクフローおよび1つのダウンリンクフロー）。m = 0。
One pair of bidirectional RTP-based media flows: N=2; one uplink on-off CBR flow over UDP: M=1 (uplink). The CBR flow has ON time at t=0s-60s and OFF time at t=60s-119s.
一対の双方向RTPベースのメディアフロー：n = 2。UDP上の1つのアップリンクON-OFF CBRフロー：M = 1（アップリンク）。CBRフローは、T = 60S~119SでT = 0S-60Sおよびオフ時間で時間を経ています。
One pair of bidirectional RTP-based media flows: N=2; one uplink off-on CBR flow over UDP: M=1 (uplink). The CBR flow has OFF time at t=0s-60s and ON time at t=60s-119s.
一対の双方向RTPベースのメディアフロー：n = 2。UDP上の1つのアップリンクON CBRフロー：M = 1（アップリンク）。CBRフローは、t = 0s-60Sでオフ時間とt = 60s-119sで時間を過ごします。
One RTP-based media flow competing against one long-lived TCP flow in the uplink direction: N=1 (uplink) and M=1 (uplink). The TCP flow has start time at t=0s and end time at t=119s.
アップリンク方向に1つの長寿命のTCPフローに対して競合する1つのRTPベースのメディアフロー：n = 1（アップリンク）およびM = 1（アップリンク）。TCPフローはT = 0Sで開始時間とT = 119Sで終了時刻を持ちます。
Single uplink RTP-based media flow: The candidate algorithm is expected to detect the path capacity constraint, to converge to the bottleneck link capacity, and to adapt the flow to avoid unwanted oscillations when the sending bit rate is approaching the bottleneck link capacity. No excessive oscillations in the media rate should be present.
シングルアップリンクRTPベースのメディアフロー：候補アルゴリズムは、ボトルネックリンク容量に収束するため、および送信ビットレートがボトルネックリンク容量に近づいているときに望ましくない振動を回避するためにフローを適応させることが期待されています。メディアレートに過度の振動が存在しないはずです。
Bidirectional RTP-based media flows: The candidate algorithm is expected to converge to the bottleneck capacity of the wired path in both directions despite the presence of measurement noise over the Wi-Fi connection. In the presence of background TCP or CBR over UDP traffic, the rate of RTP-based media flows should adapt promptly to the arrival and departure of background traffic flows.
双方向RTPベースのメディアフロー：候補アルゴリズムは、Wi-Fi接続にわたって測定ノイズが存在するにもかかわらず、両方向の有線経路のボトルネック容量に収束すると予想されます。バックグラウンドTCPまたはCBRをUDPトラフィックで存在する場合、RTPベースのメディアフローのレートは、バックグラウンドトラフィックフローの到着と出発に迅速に適応するはずです。
One RTP-based media flow competing with long-lived TCP flow in the uplink direction: The candidate algorithm is expected to avoid congestion collapse and to stabilize at a fair share of the bottleneck link capacity.
アップリンク方向に長寿命のTCPフローと競合する1つのRTPベースのメディアフロー：候補アルゴリズムは、輻輳崩壊を回避し、ボトルネックリンク容量の公正なシェアで安定すると予想されます。
The test cases in this section assume that the wired segment along the media path is well-provisioned, whereas the bottleneck exists over the Wi-Fi access network. This is to mimic the application scenarios typically encountered by users in an enterprise environment or at a coffee house.
このセクションのテストケースは、メディアパスに沿った有線セグメントがよくプロビジョニングされているのに対し、ボトルネックはWi-Fiアクセスネットワークを介して存在します。これは、企業環境またはコーヒーハウスで、通常、ユーザーが遭遇するアプリケーションシナリオを模倣することです。
Same as defined in Section 3.1.1.
セクション3.1.1で定義されていると同じです。
Test duration: 120 s
テスト期間：120 S.
Wi-Fi network characteristics:
Wi-Fiネットワークの特徴：
Radio propagation model: Log-distance path loss propagation model (see [NS3WiFi])
ラジオ伝搬モデル：ログ距離パス損失伝搬モデル（[NS3WiFi]を参照）
PHY- and MAC-layer configuration: IEEE 802.11n
PHY-およびMAC層の構成：IEEE 802.11n
MCS Index at 11: Raw data rate at 52 Mbps, 16-QAM (Quadrature amplitude modulation) and 1/2 coding rate
52Mbps、16 - QAM（直交振幅変調）および1/2符号化率でのRAWデータレートでのMCSインデックス
Wired path characteristics:
有線道の特徴：
Path capacity: 100 Mbps
パス容量：100 Mbps
One-Way propagation delay: 50 ms
一方向伝搬遅延：50ミリ秒
Maximum end-to-end jitter: 30 ms
最大エンドツーエンドジッタ：30ミリ秒
Bottleneck queue type: Drop tail
ボトルネックキュータイプ：ドロップテール
Bottleneck queue size: 300 ms
ボトルネックキューサイズ：300ミリ秒
Path loss ratio: 0%
Application characteristics
アプリケーション特性
Media traffic:
メディアトラフィック：
Media type: Video
メディアタイプ：ビデオ
Media direction: See Section 3.2.3
メディアの方向：セクション3.2.3を参照してください
Number of media sources (N): See Section 3.2.3
メディアソース数（N）：セクション3.2.3を参照してください。
Media timeline:
メディアタイムライン：
Start time: 0 s
開始時間：0 S
End time: 119 s
終了時間：119 S
Competing traffic:
競合するトラフィック：
Type of sources: long-lived TCP or CBR over UDP
ソースの種類：UDP上の長寿命のTCPまたはCBR
Number of sources (M): See Section 3.2.3
ソース数（M）：セクション3.2.3を参照してください。
Traffic direction: See Section 3.2.3
交通方向：セクション3.2.3を参照してください
Congestion control: Default TCP congestion control [RFC5681] or CBR traffic over UDP
輻輳制御：UDP上のデフォルトのTCP輻輳制御[RFC5681]またはCBRトラフィック
Traffic timeline: See Section 3.2.3
トラフィックタイムライン：3.2.3項を参照してください
This section describes a few test scenarios that are deemed as important for understanding the behavior of a candidate RTP-based congestion control scheme over a Wi-Fi network.
このセクションでは、Wi-Fiネットワーク上での候補RTPベースの輻輳制御方式の動作を理解するために重要と見なされるいくつかのテストシナリオについて説明します。
Multiple RTP-based media flows sharing the wireless downlink: N=16 (all downlink); M=0. This test case is for studying the impact of contention on the multiple concurrent media flows. For an 802.11n network, given the MCS Index of 11 and the corresponding link rate of 52 Mbps, the total application-layer throughput (assuming reasonable distance, low interference, and infrequent contentions caused by competing streams) is around 20 Mbps. A total of N=16 RTP-based media flows (with a maximum rate of 1.5 Mbps each) are expected to saturate the wireless interface in this experiment. Evaluation of a given candidate scheme should focus on whether the downlink media flows can stabilize at a fair share of the total application-layer throughput.
無線ダウンリンクを共有する複数のRTPベースのメディアフロー：n = 16（すべてダウンリンク）;m = 0。このテストケースは、複数の同時メディアフローに対する競合の影響を研究するためのものです。802.11nネットワークの場合、11のMCSインデックスと52 Mbpsの対応するリンクレート、合計アプリケーション層のスループット（合理的な距離、低干渉、および競合したストリームによって引き起こされた短い干渉）は約20 Mbpsです。この実験では、全体のN = 16のRTPベースのメディアフロー（最大1.5Mbpsの最大1.5Mbps）が飽和すると予想される。与えられた候補スキームの評価は、ダウンリンクメディアフローが総アプリケーション層のスループットの公正なシェアで安定することができるかどうかに焦点を合わせるべきである。
Multiple RTP-based media flows sharing the wireless uplink: N=16 (all uplink); M=0. When multiple clients attempt to transmit media packets uplink over the Wi-Fi network, they introduce more frequent contentions and potential collisions. Per-flow throughput is expected to be lower than that in the previous downlink-only scenario. Evaluation of a given candidate scheme should focus on whether the uplink flows can stabilize at a fair share of the total application-layer throughput.
無線アップリンクを共有する複数のRTPベースのメディアフロー：n = 16（すべてのアップリンク）;m = 0。複数のクライアントがWi-Fiネットワークを介してメディアパケットのアップリンクを送信しようとすると、より頻繁なコンテンツと潜在的な衝突が発生します。フロースループットは、前のダウンリンク専用シナリオよりも低くなると予想されます。与えられた候補スキームの評価は、アップリンクフローが総アプリケーション層スループットの公正なシェアで安定することができるかどうかに焦点を合わせるべきである。
Multiple bidirectional RTP-based media flows: N=16 (8 uplink and 8 downlink); M=0. The goal of this test is to evaluate the performance of the candidate scheme in terms of bandwidth fairness between uplink and downlink flows.
複数の双方向RTPベースのメディアフロー：n = 16（8アップリンクと8ダウンリンク）。m = 0。このテストの目的は、アップリンクフローとダウンリンクフローの間の帯域幅の公平性の観点から候補スキームの性能を評価することです。
Multiple bidirectional RTP-based media flows with on-off CBR traffic over UDP: N=16 (8 uplink and 8 downlink); M=5 (uplink). The goal of this test is to evaluate the adaptation behavior of the candidate scheme when its available bandwidth changes due to the departure of background traffic. The background traffic consists of several (e.g., M=5) CBR flows transported over UDP. These background flows are ON at time t=0-60s and OFF at time t=61-120s.
UDP上のオンオフCBRトラフィックを備えた複数の双方向RTPベースのメディアフロー：N = 16（8アップリンクと8ダウンリンク）;M = 5（アップリンク）。このテストの目的は、バックグラウンドトラフィックの出発により利用可能な帯域幅が変化したときの候補スキームの適応動作を評価することです。バックグラウンドトラフィックは、UDPを介して輸送されたいくつかの（例えば、M = 5）のCBRフローからなる。これらのバックグラウンドフローは、時刻t = 0~60sと時刻t = 61-120sでオンである。
Multiple bidirectional RTP-based media flows with off-on CBR traffic over UDP: N=16 (8 uplink and 8 downlink); M=5 (uplink). The goal of this test is to evaluate the adaptation behavior of the candidate scheme when its available bandwidth changes due to the arrival of background traffic. The background traffic consists of several (e.g., M=5) parallel CBR flows transported over UDP. These background flows are OFF at time t=0-60s and ON at times t=61-120s.
UDP上のOFF-ON CBRトラフィックを持つ複数の双方向RTPベースのメディアフロー：N = 16（8アップリンクと8ダウンリンク）;M = 5（アップリンク）。このテストの目的は、バックグラウンドトラフィックの到着による利用可能な帯域幅が変化したときの候補スキームの適応動作を評価することです。バックグラウンドトラフィックは、UDPを介して輸送されたいくつかの（例えば、M = 5）並列CBRフローからなる。これらのバックグラウンドフローは、時刻t = 0~60sおよび時点ではt = 61-120sでオフである。
Multiple bidirectional RTP-based media flows in the presence of background TCP traffic: N=16 (8 uplink and 8 downlink); M=5 (uplink). The goal of this test is to evaluate how RTP-based media flows compete against TCP over a congested Wi-Fi network for a given candidate scheme. TCP flows have start time at t=40s and end time at t=80s.
バックグラウンドTCPトラフィックの存在下で複数の双方向RTPベースのメディアフロー：N = 16（8アップリンクと8ダウンリンク）;M = 5（アップリンク）。このテストの目的は、特定の候補スキームのために輻輳したWi-Fiネットワークを介してRTPベースのメディアフローがTCPとどのように競合するかを評価することです。TCPフローはT = 40Sで開始時間とT = 80Sで終了時刻を有する。
Varying number of RTP-based media flows: A series of tests can be carried out for the above test cases with different values of N, e.g., N=[4, 8, 12, 16, 20]. The goal of this test is to evaluate how a candidate scheme responds to varying traffic load/demand over a congested Wi-Fi network. The start times of the media flows are randomly distributed within a window of t=0-10s; their end times are randomly distributed within a window of t=110-120s.
さまざまな数のRTPベースのメディアフロー：N = [4,8,12,16,20]の異なる値を有する上記の試験ケースについて一連の試験を実施することができる。このテストの目的は、候補スキームが混雑したWi-Fiネットワークを介した交通荷重/需要の変動にどのように対応するかを評価することです。メディアフローの開始時間は、T = 0~10Sのウィンドウ内にランダムに分布しています。それらの終了時間は、t = 110-120sのウィンドウ内でランダムに分散されます。
Multiple downlink RTP-based media flows: Each media flow is expected to get its fair share of the total bottleneck link bandwidth. Overall bandwidth usage should not be significantly lower than that experienced by the same number of concurrent downlink TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario. The end-to-end delay and packet loss ratio experienced by each flow should be within an acceptable range for real-time multimedia applications.
複数のダウンリンクRTPベースのメディアフロー：各メディアフローは、ボトルネックリンク帯域幅の公正シェアを取得すると予想されます。全体的な帯域幅の使用法は、同じ数の同時ダウンリンクTCPフローが経験するものよりも大幅に低くてはいけません。つまり、複数の同時TCPフローの動作は、このテストシナリオのパフォーマンスベンチマークとして使用されます。各フローが受けるエンドツーエンドの遅延とパケット損失比は、リアルタイムマルチメディアアプリケーションの許容範囲内にある必要があります。
Multiple uplink RTP-based media flows: Overall bandwidth usage by all media flows should not be significantly lower than that experienced by the same number of concurrent uplink TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario.
複数のアップリンクRTPベースのメディアフロー：すべてのメディアフローによる全体的な帯域幅の使用法は、同じ数の同時アップリンクTCPフローによって経験されるものよりも大幅に低くてはいけません。つまり、複数の同時TCPフローの動作は、このテストシナリオのパフォーマンスベンチマークとして使用されます。
Multiple bidirectional RTP-based media flows with dynamic background traffic carrying CBR flows over UDP: The media flows are expected to adapt in a timely fashion to the changes in available bandwidth introduced by the arrival/departure of background traffic.
UDP上でCBRフローを運ぶ動的バックグラウンドトラフィックを持つ複数の双方向RTPベースのメディアフロー：メディアフローは、バックグラウンドトラフィックの到着/出発によって導入された利用可能な帯域幅の変化に適時に適応すると予想されます。
Multiple bidirectional RTP-based media flows with dynamic background traffic over TCP: During the presence of TCP background flows, the overall bandwidth usage by all media flows should not be significantly lower than those achieved by the same number of bidirectional TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario. All downlink media flows are expected to obtain similar bandwidth as each other. The throughput of each media flow is expected to decrease upon the arrival of TCP background traffic and, conversely, increase upon their departure. Both reactions should occur in a timely fashion, for example, within 10s of seconds.
TCP経由の動的バックグラウンドトラフィックを備えた複数の双方向RTPベースのメディアフロー：TCPバックグラウンドフローの存在中、すべてのメディアフローによる全体的な帯域幅使用量は、同じ数の双方向TCPフローによって達成されるものよりも大幅に低くてはいけません。つまり、複数の同時TCPフローの動作は、このテストシナリオのパフォーマンスベンチマークとして使用されます。すべてのダウンリンクメディアフローは、互いに同様の帯域幅を得ることが期待されています。各メディアフローのスループットは、TCPバックグラウンドトラフィックの到着時に減少すると予想され、逆に出発時に増加します。両方の反応は、例えば10秒以内にタイムリーに起こるべきである。
Varying number of bidirectional RTP-based media flows: The test results for varying values of N -- while keeping all other parameters constant -- is expected to show steady and stable per-flow throughput for each value of N. The average throughput of all media flows is expected to stay constant around the maximum rate when N is small, then gradually decrease with increasing value of N till it reaches the minimum allowed rate, beyond which the offered load to the Wi-Fi network exceeds its capacity (i.e., with a very large value of N).
さまざまな数の双方向RTPベースのメディアフロー：N - のさまざまなパラメータを定数に保ちながら、N - のさまざまな値のテスト結果は、Nの各値に対して定常的で安定したフローのスループットを表示すると予想されます。すべての平均スループットメディアフローは、Nが小さいときに最大レートを中心とし、その後、Wi-Fiネットワークへの提供された負荷がその容量を超える最小許容レートに達するまで、最小許容レートに達するまで徐々に減少すると予想されます（つまり、nの非常に大きな値。
The EDCA/WMM mechanism defines prioritized QoS for four traffic classes (or Access Categories). RTP-based real-time media flows should achieve better performance in terms of lower delay and fewer packet losses with EDCA/WMM enabled when competing against non-interactive background traffic such as file transfers. When most of the traffic over Wi-Fi is dominated by media, however, turning on WMM may degrade performance since all media flows now attempt to access the wireless transmission medium more aggressively, thereby causing more frequent collisions and collision-induced losses. This is a topic worthy of further investigation.
EDCA / WMMメカニズムは、4つのトラフィッククラス（またはアクセスカテゴリ）の優先順位付けQoSを定義します。RTPベースのリアルタイムメディアフローは、ファイル転送などの非対話型のバックグラウンドトラフィックと競合するときに、遅延が低くなり、EDCA / WMMが有効になっているパケット損失が少なくなります。しかし、Wi-Fi経由のトラフィックのほとんどがメディアによって支配されている場合、すべてのメディアフローは今や積極的に無線伝送媒体にアクセスしようとし、それによってより頻繁な衝突と衝突損失を引き起こすので、WMMをオンにするとパフォーマンスが低下する可能性があります。これはさらなる調査に値するトピックです。
As discussed in [Heusse2003], the presence of clients operating over slow PHY-layer link rates (e.g., a legacy 802.11b device) connected to a modern network may adversely impact the overall performance of the network. Additional test cases can be devised to evaluate the effect of clients with heterogeneous link rates on the performance of the candidate congestion control algorithm. Such test cases, for instance, can specify that the PHY-layer link rates for all clients span over a wide range (e.g., 2 Mbps to 54 Mbps) for investigating its effect on the congestion control behavior of the real-time interactive applications.
[HEUSSE2003]で説明したように、現代のネットワークに接続された遅いPhy層リンク速度（例えば、従来の802.11b装置）を介して動作するクライアントの存在は、ネットワークの全体的な性能に悪影響を及ぼす可能性がある。追加のテストケースは、候補輻輳制御アルゴリズムの性能に対する不均一なリンク速度を持つクライアントの効果を評価するために考案することができます。例えば、このようなテストケースは、リアルタイム対話型アプリケーションの輻輳制御挙動に対するその効果を調査するために、すべてのクライアントのPHY層リンクレートが広範囲（例えば、2 Mbpsから54 Mbps）にわたってスパンすることを指定できます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security considerations in [RFC8868] and the relevant congestion control algorithms apply. The principles for congestion control are described in [RFC2914], and in particular, any new method must implement safeguards to avoid congestion collapse of the Internet.
[RFC8868]のセキュリティ上の考慮事項と関連する輻輳制御アルゴリズムが適用されます。輻輳制御の原理は[RFC2914]に記載されており、特に、インターネットの輻輳崩壊を避けるために安全な方法を実装する必要があります。
Given the difficulty of deterministic wireless testing, it is recommended and expected that the tests described in this document would be done via simulations. However, in the case where these test cases are carried out in a testbed setting, the evaluation should take place in a controlled lab environment. In the testbed, the applications, simulators, and network nodes ought to be well-behaved and should not impact the desired results. It is important to take appropriate caution to avoid leaking nonresponsive traffic with unproven congestion avoidance behavior onto the open Internet.
決定論的ワイヤレステストの難しさを考えると、この文書で説明されているテストはシミュレーションによって行われることを推奨します。ただし、これらのテストケースがテストベッド設定で行われる場合は、管理ラボ環境で評価が行われるべきです。テストベッドでは、アプリケーション、シミュレータ、およびネットワークノードが行動的に行動的であるべきであり、望ましい結果に影響を与えるべきではありません。オープンインターネットへの輻輳回避行動を伴う非応答的なトラフィックを漏らすのを避けるために適切な注意を取ることが重要です。
[HO-deploy-3GPP] 3GPP, "Physical layer aspects for evolved Universal Terrestrial Radio Access (UTRA)", TS 25.814, October 2006, <http://www.3gpp.org/ftp/specs/ archive/25_series/25.814/25814-710.zip>.
[HO-Deploy-3GPP] 3GPP、「Evolved Universal Ladial Radio Access（UTRA）」、TS 25.814、2006年10月、<http://www.3gpp.org/ftp/specs/ archive / 25_series / 25.814/ 25814-710.zip>。
[IEEE802.11] 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 802.11-2012, <https://ieeexplore.ieee.org/document/7786995>.
[IEEE802.11] IEEE、「情報の標準」現地と首都圏の地域と首都圏ネットワーク間の電気通信と情報交換 - 特有の要件部11：無線LAN媒体アクセス制御（MAC）と物理層（PHY）仕様 "、IEEE802.11-2012、<https://ieeexplore.ieee.org/document/7786995>。
[NS3WiFi] "ns3::YansWifiChannel Class Reference", <https://www.nsnam.org/doxygen/ classns3_1_1_yans_wifi_channel.html>.
[NS3WiFi] "NS3 :: YANSWIFIFICHANNELクラスリファレンス"、<https://www.nsnam.org/doxygen/ classns3_1_1_yans_wifi_channel.html>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V.およびE.Blanton、「TCP輻輳制御」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https：//www.rfc-editor.org/info/RFC5681>。
[RFC8867] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating Congestion Control for Interactive Real-Time Media", RFC 8867, DOI 10.17487/RFC8867, January 2021, <https://www.rfc-editor.org/info/rfc8867>.
[RFC8867] Sarker、Z.、Singh、V.、Zhu、X.、およびM. Ramalho、「インタラクティブリアルタイムメディアの輻輳制御を評価するためのテストケース」、RFC 8867、DOI 10.17487 / RFC8867、2021年1月、<https://www.rfc-editor.org/info/rfc8867>。
[RFC8868] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Control for Interactive Real-Time Media", RFC 8868, DOI 10.17487/RFC8868, January 2021, <https://www.rfc-editor.org/info/rfc8868>.
[RFC8868] Singh、V.、OTT、J.、およびS. Holmer、「インタラクティブリアルタイムメディアのための輻輳制御の評価」、RFC 8868、DOI 10.17487 / RFC8868、<https：///www.rfc-editor.org/info/rfc8868>。
[Heusse2003] Heusse, M., Rousseau, F., Berger-Sabbatel, G., and A. Duda, "Performance anomaly of 802.11b", IEEE INFOCOM 2003, Twenty-second Annual Joint Conference of the IEEE Computer and Communications Societies, DOI 10.1109/INFCOM.2003.1208921, March 2003, <https://ieeexplore.ieee.org/document/1208921>.
[HEUSSE2003] Heusse、M.、Rousseau、F.、Berger-Sabbatel、G.、A. DUDA、「演奏異常：802.11Bのパフォーマンス異常」、IEEE Infocom 2003、IEEEコンピュータおよびコミュニケーション社会の22秒の合同会議、DOI 10.1109 / infcom.2003.1208921、<https://ieeexplore.ieee.org/document/1208921>。
[HO-def-3GPP] 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 21.905, December 2009, <http://www.3gpp.org/ftp/specs/ archive/21_series/21.905/21905-940.zip>.
[HO-DEF-3GPP] 3GPP、「3GPP仕様のための語彙」、3GPP TS 21.905、2009年12月、<http://www.3gpp.org/ftp/specs/ archive / 21_series / 21.905 / 21905-940.ZIP>。
[HO-LTE-3GPP] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", 3GPP TS 36.331, December 2011, <http://www.3gpp.org/ftp/specs/ archive/36_series/36.331/36331-990.zip>.
[HO-LTE-3GPP] 3GPP、「普遍的な地上無線アクセス（E-UTRA）;無線リソース制御（RRC）; 2011年12月、2011年12月、<http://www.3gpp.org/FTP / SPEC / ARCHIVE / 36_SERIES / 36.331 / 36331-990.ZIP>。
[HO-UMTS-3GPP] 3GPP, "Radio Resource Control (RRC); Protocol specification", 3GPP TS 25.331, December 2011, <http://www.3gpp.org/ftp/specs/ archive/25_series/25.331/25331-990.zip>.
[HO-UMTS-3GPP] 3GPP、「無線リソース制御（RRC）;プロトコル仕様」、3GPP TS 25.331、2011年12月、<http://www.3gpp.org/ftp/specs/ archive / 25_series / 25.331 / 25331-990.zip>。
[NS-2] "ns-2", December 2014, <http://nsnam.sourceforge.net/wiki/index.php/Main_Page>.
[NS-2] "NS-2"、2014年12月、<http://nsnam.sourceforge.net/wiki/index.php/main_page>。
[NS-3] "ns-3 Network Simulator", <https://www.nsnam.org/>.
[NS-3] "NS-3ネットワークシミュレータ"、<https://www.nsnam.org/>。
[QoS-3GPP] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203, June 2011, <http://www.3gpp.org/ftp/specs/ archive/23_series/23.203/23203-990.zip>.
[QoS-3GPP] 3GPP、「ポリシー・充電制御アーキテクチャ」、3GPP TS 23.203、2011年6月、<http://www.3gpp.org/ftp/specs/ archive / 23_series / 23.203 / 23203-990.zip>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914] Floyd、S.、「輻輳制御原理」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<https：//www.rfc-editor.org/info/rfc2914>。
Contributors
貢献者
The following individuals contributed to the design, implementation, and verification of the proposed test cases during earlier stages of this work. They have helped to validate and substantially improve this specification.
次の個人は、この作品の以前の段階で提案されたテストケースの設計、実施、および検証に貢献しました。彼らはこの仕様を検証し、実質的に改善するのを助けました。
Ingemar Johansson <ingemar.s.johansson@ericsson.com> of Ericsson AB contributed to the description and validation of cellular test cases during the earlier stage of this document.
Ericsson ABのIngemar Johansson <Ingemar.S.Johansson@ericsson.com>は、この文書の以前の段階でのセルラーテストケースの説明と検証に貢献しました。
Wei-Tian Tan <dtan2@cisco.com> of Cisco Systems designed and set up a Wi-Fi testbed for evaluating parallel video conferencing streams, based upon which proposed Wi-Fi test cases are described. He also recommended additional test cases to consider, such as the impact of EDCA/WMM usage.
Cisco SystemsのWei-Tian Tan <dtan2@cisco.com>は、提案されたWi-Fiテストケースを説明するために、並列ビデオ会議ストリームを評価するためのWi-Fiテストベッドを設計および設定しました。彼はまた、EDCA / WMMの使用法の影響など、考慮すべき追加のテストケースを推奨しました。
Michael A. Ramalho <mar42@cornell.edu> of AcousticComms Consulting (previously at Cisco Systems) applied lessons from Cisco's internal experimentation to the draft versions of the document. He also worked on validating the proposed test cases in a virtual-machine-based lab setting.
Michael A. Ramalho <Mar42@cornell.edu> AcousticCommsコンサルティング（以前はシスコシステムズ）のドラフト版のドラフトバージョンへのレッスン。彼はまた、仮想マシンベースのラボ設定で提案されたテストケースの検証に取り組みました。
Acknowledgments
謝辞
The authors would like to thank Tomas Frankkila, Magnus Westerlund, Kristofer Sandlund, Sergio Mena de la Cruz, and Mirja Kühlewind for their valuable inputs and review comments regarding this document.
著者らは、フランクキラ、Magnus Westerlund、Kristofer Sandlund、Sergio Mena de la Cruz、およびMirjaKühlewindに感謝し、この文書に関するコメントを確認したいと思います。
Authors' Addresses
著者の住所
Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83 Stockholm Sweden
Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 SE-164 83ストックホルムスウェーデン
Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com
Xiaoqing Zhu Cisco Systems Building 4 12515 Research Blvd Austin, TX 78759 United States of America
Xiaoqing Zhu Cisco Systems Building 4 12515 Research Blvd Austin、TX 78759アメリカ合衆国
Email: xiaoqzhu@cisco.com
Jiantao Fu Cisco Systems 771 Alder Drive Milpitas, CA 95035 United States of America
Jiantao Fu Cisco Systems 771 Alder Drive Milpitas、CA 95035アメリカ合衆国
Email: jianfu@cisco.com