WiFi アドバイザリ & デザインサービス WiFi 教育 WiFi 診断 & 最適化 ミッドレンジ 802.11ac アクセスポイントのクライアント密度 / ビデオパフォーマンス比較 Devin K. Akin, CEO Devin@DivDyn.com 2017 年 9 月バージョン 1.00
エグゼクティブサマリー このドキュメントでは 高クライアント密度環境で複数ベンダーのミッドレンジ 802.11ac Wave 2 アクセスポイント (AP) のパフォーマンスを詳細に説明しています 主なデータトラフィックタイプとしてビデオを使用しました 従来の競合テストでは AP に負荷をかける方法としてファイル転送を使用した場合の総データスループットを重視する傾向にありました ビデオを含めた最新の公開ストレステストは 2013 年に発行されたもののようです このテストスイートでは 主なデータ負荷としてビデオトラフィックを選択しました 理由は簡単で 今日の多くのネットワークではビデオがネットワークトラフィック量の大半を占めているからです 最新の Cisco Visual Networking Index 1 には次のような内容が記載されています 世界の IP ビデオトラフィックは 2016 年から 2021 年までに 3 倍に増加する これは CAGR 26 % に相当する インターネットビデオトラフィックは 2016 年から 2021 年までに 4 倍に増加する これは CAGR 31 % に相当する ビジネス IP トラフィックは 2016 年から 2021 年までに CAGR 21 % の速度で増加する 高度なビデオコミュニケーションを採用する企業が増えるに伴い ビジネス IP トラフィックは 2016 年から 2021 年までに 3 倍に増加する 最新の Ericsson Mobility Report 2 には以下のような内容が記載されています モバイルビデオトラフィックは 2022 年までに年間約 50 % 成長すると予測される これは全モバイルトラフィックの 4 分の 3 近く 2016 年後半に タブレットのモバイルデータビデオトラフィックは 60% に近づいた ビデオはバンド幅を大量に消費するだけでなく e メール ファイル転送 閲覧など大部分のデータアプリケーションと比較した場合に エンドユーザーの体験の質に大きく影響するという点で突出しています e メール添付ファイルのダウンロード速度が 1 2 秒遅くても ユーザーはおそらく気づかないでしょう しかし ビデオ失速はすぐにわかります ユーザーが低品質の ( 失速 ) ビデオを経験する可能性は そのユーザーが高クライアント密度環境にいる場合に高くなります このテストスイートでは 高密度環境を 60 個のクライアントと定義しています 1 Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2016 2021 ホワイトペーパー 2 Ericsson Mobility Report 2017 年 6 月 2
まとめると このテストはビデオトラフィックと高クライアント密度を組み合わせて AP にストレスをかけるよう設計されています どちらの条件も今日の WLAN ネットワーク環境で一般的なものです ラッカスのテクニカルチームがテストサイトと機器を用意し このドキュメントに記載されているすべてのテストを実施しました 筆者は すべてのテスト機器 ソフトウェア 構成 結果を確認して検証しました 施設内の物理的な AP とクライアントは 実世界 におけるベストプラクティスの設計パラメーターを使用してセットアップしました この検証済みの構成で すべてのベンダーを同一の条件の下でテストしました 筆者について Devin Akin は ベンダー中立的なトレーニングおよび認定において事実上のグローバル標準である CWNP の共同創立者です Akin (CWNE #1) は IT 分野で 20 年以上の経験があり うち 15 年以上は WLAN を専門に扱っています また 革新的な WiFi 設計 検証 パフォーマンスソリューションに特化した WiFi システムインテグレーター / トレーニング組織である Divergent Dynamics の創立者で CEO です このテストはどのようなものですか? このレポートでは ビデオトラフィック負荷をかけた AP のパフォーマンスを測定するために設計された一連のテストについて説明しています 実世界の導入に近い環境を用意するため ミッドレンジ 802.11ac Wave 2 3x3:3 AP を選択しました 特定の製造元が 3x3:3 AP モデルを作っていない場合は 次位モデルを使用しました 価格が手頃なこと 多数の WLAN 環境でよく使用されるローレンジからミッドレンジの広範なワイヤレスデバイスの代用となることから 2x2:2 802.11ac 無線機能を持つ Chromebook を選択しました Chromebook は小中高等学校や初等教育でも広く使用されているため このテストスイートは特にそのような環境にとって関連性が高くなります ビデオテスト中にビデオ以外のデータトラフィックでネットワークに負荷をかけるために Apple Mac Mini を使用しました 3
このテストにはどのような意義がありますか? ビデオトラフィックは全データトラフィックの大部分を占めるため ビデオを配信するネットワークのパフォーマンスが低いと 他のほとんどのデータタイプのトラフィックと比較した場合に エンドユーザーの体験に与える影響が極めて高くなる可能性があります このため WLAN がビデオのサービス品質を確保できることは あらゆるタイプの組織にとって基本的な要件です サービス品質 (QoS) を保証する仕組みは 信頼性と安定性の高いアプリケーションを提供するための基盤です そのような QoS 管理は 大企業から教育までさまざまな業種の企業にとって不可欠です サービス品質は 急増するモノのインターネット (IoT) デバイスに対応するためにも極めて重要です 多数の IoT デバイスが UDP プロトコルである Bacnet 経由で通信を行うため ( 時間 / 遅延に弱い ) ビデオデバイスや音声デバイスと同じレベルのパフォーマンスを目標にする必要があります テスト環境テストは 米国カリフォルニア州ユニオンシティ市にある中学校の 2 つの隣り合わせた教室で実施しました 教室には何もなく クリーンな無線周波 (RF) 環境であったことが この場所を選択した主な理由でした 各 WLAN 製造元の機器は シングル SSID でビデオとデータトラフィックを送信するように設定と構成を行いました テスト対象の各 AP は 一方の教室の 2 つの教室を隔てる壁の反対側に設置しました 4
テスト対象のアクセスポイント このテストでは以下のハードウェアとファームウェアを使用しました ベンダー AP/ コントローラーソフトウェアバージョン MIMO タイプ Ruckus R610 と SZ100 3.5.0.0.832 3x3:3 11ac Aruba AP-305 と 7205 6.5.1.2 3x3:3 11ac Aerohive AP250 HiveOS 8.0r1 ビルド 161337 3x3:3 11ac Meraki MR42 クラウド 3x3:3 11ac Cisco 1850i と 5508 8.3.102.0 4x4:4 11ac 図 1 - テスト対照の AP モデル テスト方法 WLAN 構成すべてのテストは 5 GHz 帯域幅で実行しました これは 高密度環境の業界推奨ベストプラクティスです すべてのクライアントにバンド幅 40 MHz のチャネルを使用し PSK でセキュアにして 1 つの SSID で WLAN に接続しました 80 MHz バンド幅を使用すれば 802.11ac より高いデータレートに対応できはしますが 高密度環境ではチャネル競合によってチャネル再使用率が低下するため そのように大きなチャネルバンド幅は推奨されません テスト中に AP のチャネルが変更されないようにするために 各 AP は手動で 149 以降に割り当てました 他のデバイスがこのチャネルを使用しないように このスペクトラムをスイープしました AP の 1 つ (Aerohive AP250) は第 2 無線を 5 GHz 無線として使用する構成 ( デュアル 5 GHz 無線モード ) に対応するため AP250 は 5GHz 無線を 1 つ有効にした状態と 2 つの 5GHz 無線を両方有効にした状態とで 2 度テストしました 製造元の推奨に基づき 第 1 無線と第 2 無線は 80 MHz で分離しました 第 1 無線はチャネル 40 を 第 2 無線はチャネル 149 を使用するように構成しました イーサネットスイッチの構成有線インフラには Ruckus ICX 7150 スイッチを使用しました すべてのデバイスを レイヤー 2 VLAN を使用してギガビットイーサネットポートに接続しました ビデオ構成各 Chromebook クライアントに 1.6 Mbps ユニキャスト TCP ビデオをストリーミングするために Microsoft Windows メディアサーバー 6 台を使用しました ビデオがキャッシュされないように Chrome ブラウザオペレーティングシステムの シークレット 5
モードで実行しました ビデオはループさせず 各テストで最初から再生しました すべてのビデオトラフィックは 有線スイッチの DSCP 40 でマーキングしました すべてのクライアントに 1 分間の実行時間を与え データ負荷をかける前の失速数をカウントしました ビデオ失速はごく短い場合もあるため ビデオ失速の定義は緩めに設定しました 各テスト段階の終わりにビデオが開始していない または失速状態の場合に失速とみなす と定義しました ビデオクライアントが実行を開始したら Mac Mini クライアントを Ixia Chariot 7.3 EA エンドポイント ( 各 1 ペア ) として構成して ビデオ以外のデータトラフィックを WLAN に 1 分間追加しました 異なるクラスのトラフィック ( ビデオおよびデータ ) の間で利用可能なバンド幅の奪い合いを起こすために ネットワークに十分な負荷をかけました 制御を厳密に行って一貫した負荷をかけるために UDP 形式のデータトラフィックを選択しました ビデオがただちに再生され始めなかった場合は 2 回リトライしました 2 度目にも再生されなかった場合は失速とみなし 基準カウント ( ネットワーク負荷なしの状態でビデオを再生したビデオクライアント ) からマイナスし ネットワーク負荷をかけた状態での失速クライアント ( 失速状態が続いていた場合 ) としてカウントしました 規定の 1 分間のデータ負荷が終了する時点で 同じ失速条件を使用して 失速ビデオクライアント数を再度カウントしました データクライアント (Mac Mini) の最終的な総スループットは Chariot 3 からレポートされた値としました クライアント 2x2:2 Chromebook クライアント 60 台と Mac Mini クライアント 30 台を使用しました クライアント数とクライアントの組み合わせは 以下の 2 度のテストで変更されています 3 Chariot スクリプトは UDP_RFC768 を無効にした標準のパフォーマンステストスクリプトでした これは UDP スループットテスト向けに Ixia から推奨されている方法です 6
図 2 - テスト対象のネットワークトポロジー テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント 目的隣接した教室でデータ専用クライアント 30 台を追加して メインの教室にある Chromebook クライアント 30 台のビデオ品質への影響を判断します 測定基準は データに負荷をかける前と後に AP で同時に対応できるビデオの数です 説明ビデオストリームは 30 台の Chromebook で手動で開始しました すべてのビデオが再生開始してから 1 分後に 隣の教室にある 30 台の Mac Mini クライアントにデータをプッシュしました 非失速ビデオクライアントの数を記録し さらにデータ専用クライアントとの関連で総データスループットを記録しました 各テストでは いったん失速したが ネットワーク負荷停止後に再開したビデオの数も記録しました 各テストは 3 回実施しました 成功条件ネットワーク負荷をかける前と負荷をかけている間に AP が 30 台のビデオクライアントに非失速ビデオを正常に配信し しかも同時にデータ専用クライアントにデータを 7
配信したときに成功とみなしました 負荷をかけている間にビデオが失速する場合は 負荷を停止したときにビデオが再開するはずです これにより ネットワーク負荷をかける前 かけている間 負荷停止後に一貫したパフォーマンスを示します 総データスループットについては 絶対的な成功条件値はありません 図 3 - Chromebook (30 クライアント ) でのストリーミングビデオと Mac Mini (30 クライアント ) でのデータダウンロードを同時実行した場合 結果ネットワーク負荷を停止し AP がビデオトラフィックのみを配信しているときは テスト対象のすべての AP が 30 台のビデオストリーミングクライアントに対応できました データ負荷をかけると 大半の AP はビデオストリームすべてに対応することはできませんでした 以下 ( 図 4) に示すように 非失速ビデオ接続数は 30 クライアント ( 最高 ) からゼロ ( 最低 ) まで幅がありました 記載されているテスト結果はすべて 3 回実施したテストの平均値です 8
図 4 テスト 1 の結果 - 負荷をかけた場合の非失速ビデオ ネットワーク負荷は時間の経過にともない上下するため 負荷からネットワークがどのように回復するかを測定すれば パフォーマンスをより詳細に分析できます 以下のチャートは データ負荷をかける前 かけている間 負荷停止後の 非失速ビデオの数を示しています 図 5 - テスト 1 の結果 - ネットワークデータ負荷前 負荷中 負荷後 9
図 6 - テスト 1 の結果 - ネットワークデータ負荷前 負荷中 負荷後 データネットワーク負荷をかけた場合とかけていない場合の両方で 30 台のクライアントすべてに非失速ビデオを配信できた AP は 1 つ (Ruckus R610) だけでした R610 はまた データ専用 Mac Mini クライアントでも最高の総データスループットを実現しました 図 7 テスト 1 の結果 - 総データスループット 10
結論 高解像度ビデオを 30 台のラップトップがある教室にストリーミングしながら 同時に 200Mbps のデータスループットを別の 30 台のクライアント (Mac Mini) にプッシュすると 非常に高パフォーマンスの無線ドライバーチューニングが見られます R610 は全競合をたやすく打ち負かし 各クライアントデバイスへのビデオ配信目標を達成した唯一のアクセスポイントでした テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント 目的隣接した教室でデータ専用クライアント 2 台を追加して 両方の教室にある Chromebook クライアント 60 台のビデオ品質への影響を判断します 測定基準は データに負荷をかける前と後に AP で同時に対応できるビデオの数です 説明ビデオストリームは 60 台の Chromebook クライアントで手動で開始しました すべてのビデオが開始してから 1 分後に 隣の教室にある 2 台の Mac Mini クライアントにデータをプッシュしました 非失速ビデオクライアントの数を記録し さらにデータ専用クライアントとの関連で総データスループットを記録しました 各テストでは いったん失速したが ネットワーク負荷停止後に再開したビデオの数も記録しました 各テストは 3 回実施しました 成功条件ネットワーク負荷をかける前と負荷をかけている間に AP が 60 台のビデオクライアントに非失速ビデオを正常に配信し しかも同時にデータ専用クライアントにデータを配信したときに成功とみなしました 総データスループットについては 絶対的な成功条件値はありません 11
図 8 - Chromebook (30 クライアント ) でのストリーミングビデオと Mac Mini (2 クライアント ) でのデータダウンロードを同時実行した場合 結果最初のテストケースと異なり 2 台の AP (Ruckus R610 Aruba AP-305) のみが データ負荷を同時にかけない状態で非失速ビデオを 60 台のクライアントに配信できました 最初のテストケースと同様 データ負荷をかけると 大部分のベンダーで非失速ビデオの数が尐なくなりました 以下 ( 図 9) に示すように 非失速ビデオ接続は 60 クライアント ( 最高 ) から 5 クライアント ( 低い ) まで幅がありました 記載されているテスト結果はすべて 3 回実施したテストの平均値です データネットワーク負荷をかけた場合とかけていない場合の両方で 60 台のクライアントすべてに非失速ビデオを配信できた AP は 1 つ (Ruckus R610) だけでした 12
図 9 テスト 2 の結果 - 負荷をかけた場合と負荷をかけない場合の対象ビデオクライアントの非失速ビデオ数 ビデオテスト中 全 AP がデータトラフィックをデータ専用クライアントに正常に配信できました Ruckus R610 と Cisco 1850 は ほぼ同等の総スループットをデータ専用クライアントに配信しましたが Cisco では 3 分の 2 のビデオストリーミングクライアントでビデオが失速しました 図 10 テスト 2 の結果 - 総データスループット 13
結論 2 つの教室にある各 30 台のラップトップ ( 合計 60 台のビデオラップトップ ) に高解像度ビデオをストリーミングしながら 同時に 150Mbps の UDP データに対応して QoS を維持できれば それは まさに驚くべき性能です Ruckus R610 は このテストの 60 クライアントビデオ配信目標を達成した唯一の AP でした 実証されたこのレベルの実行能力は Ruckus が仕様どおりの価格 / パフォーマンスを実現できることを証明しています まとめと結論 各テスト手順を実施する際には スペクトラム分析ツール プロトコル分析ツール ハンドヘルド診断プラットフォームなどの診断ツールを使用して それぞれの結果を検証しました システム構成は ベストプラクティスと製造元の推奨に照らして検証しました すべてのテストで 一貫性を保つためにエアタイムの消費を監視しました すべての結果は テスト時に筆者が目視で検証して記録しました ここに掲載されている各メトリクスは パフォーマンスの全体像と 実世界におけるテストの有効性に大きく貢献します たとえば ビデオだけが AP を通過することはまれです データトラフィックが多数のビデオフローに与える影響を評価したのはこのためです ビデオクライアントの数は 実際の教室を想定して決めました これにより 見込み顧客は各自の現場を想定し それぞれのベンダーを使用した場合にどのようになるかを予測できます ネットワーク全体のキャパシティは 利用可能なエアタイム プロトコル効率 および QoS が有効になったトラフィック配信によって決まります すべてのテストで エアタイムの消費 ( チャネル使用量 ) は予想どおり高くなり 75% 近くになることも頻繁にありました これは チャネルが飽和点に近づいていたことを示します しかし Ruckus R610 だけは 十分な QoS とトラフィック処理効率を実現し チャネルが飽和点に近づいていたにも関わらず すべてのテストで高品質ビデオを各クライアントデバイスに配信するという目標を達成しました 筆者は ラッカスチームが各テストのベンダー中立性と公平さを保ったこと さらに 不確かな点がある場合は必要に応じて常に他社が有利になるよう解釈したことは称賛に値します ここに記載する結果はすべて テストで収集された生データを 四捨五入や変更を加えずに そのまま引用しています テストメソドロジーは公平で 全ベンダーに同様に適用され 各ベンダーのテスト結果は偏見なしにそのまま受け入れました 14
今日 かつてないほど大量のワイヤレスデバイスとアプリケーションがネットワークを通過しているのは衆知の事実ですが これらのデバイスがどのように使用されているかを把握することは非常に重要です 802.11 規格がアップグレードされるたびに (802.11 802.11n そして現在は 802.11ac) データレートは高くなっていますが 必ずしもスループットの向上が伴うわけではありません スループット そして最終的にはユーザー体験の向上に直結するのは すべてのネットワークが対応しなければならないモビリティの課題です ピンポン スティッキー ドミナント チャティデバイスの課題は 小規模ネットワークでも問題になりますが 高密度施設では大惨事になります これらすべての課題に対応するネットワークインフラが 最終的には最高の総スループットと最高とユーザー体験を実現するのです 15
付録 A: Ruckus R610 の結果 テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 30 中 30 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 201 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 60 中 60 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 60 (100%) 合計総ダウンリンク UDP スループット (2 クライアント ) 150 Mbps 16
付録 B:Aruba 305 の結果 テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 30 中 11 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 76 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 60 中 60 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 9 (15%) 合計総ダウンリンク UDP スループット (2 クライアント ) 85 Mbps 17
付録 C: Aerohive AP250 の結果 テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント (5 GHZ 無線 x 1) データ負荷がない場合の合計非失速ビデオストリーム数 (30 中 ) 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 (30 中 ) 30 中 0 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 95 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント ( シングル 5 GHZ 無線 ) データ負荷がない場合の合計非失速ビデオストリーム数 60 中 45 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 5 (15%) 合計総ダウンリンク UDP スループット (2 クライアント ) 78 Mbps 18
テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント ( デュアル 5 GHZ 無線 ) データ負荷がない場合の合計非失速ビデオストリーム数 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 30 中 0 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 94 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント (5 GHZ 無線 x 2) データ負荷がない場合の合計非失速ビデオストリーム数 60 中 57 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 18 (15%) 合計総ダウンリンク UDP スループット (2 クライアント ) 73 Mbps 19
付録 D:Meraki MR42 の結果 テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 30 中 13 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 120 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 60 中 41 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 28 (15%) 合計総ダウンリンク UDP スループット (2 クライアント ) 62 Mbps 20
付録 E:Cisco 1850i の結果 テスト 1: 30 台のビデオクライアントと 30 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 30 中 30 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 30 中 8 (100%) 合計総ダウンリンク UDP スループット (30 クライアント ) 96 Mbps テスト 2: 60 台のビデオクライアントと 2 台のデータクライアント データ負荷がない場合の合計非失速ビデオストリーム数 60 中 28 (100%) データ負荷がある場合の合計非失速ビデオストリーム数 60 中 19 (15%) 合計総ダウンリンク UDP スループット (2 クライアント ) 155 Mbps 21