Wi-Fiスループットの検証：テストおよびモニタリングガイド

はじめに

このドキュメントでは、大規模なWi-Fiネットワークのスループットの問題を監視およびトラブルシューティングする方法について説明します。

CONTEXT

Wi-Fiネットワークでは、エンドユーザが問題を認識するタイプはそれほど多くありません。

報告される問題の範囲は次のとおりです。

• クライアントが接続できない。
• クライアントが突然切断されるか、
• ユーザデバイス上のアプリケーションの知覚された速度は満足のいくものではない。

これらの単純な症状の背後には、DNSの問題やインターネット接続の問題など、実際のWi-Fiネットワークを含まない問題が何百も存在する可能性があります。

Cisco Catalyst Centerなどの管理サーバは、管理者が特定の問題のトラブルシューティングを行う際に役立ちます。この記事では、Catalyst Centerで簡単に確認および修復できる多くの種類の日常的な問題については詳しく説明しません。代わりに、このドキュメントでは、ネットワークが遅いというエンドユーザからのより漠然としたフィードバックに焦点を当てています。

テスト方法は？ネットワーク全体の実際のスループットを検証する方法全体的なエンドユーザエクスペリエンスを向上させるために、スピード関連の問題を実行可能な項目にトリアージする方法

このドキュメントで説明する質問はすべて次のとおりです。

予想される最大スループットの定義

各ネットワークの最初の質問は、「潜在的かつ現実的に到達できる最大速度は何か」です。

Wi-Fiは共有メディアであるため、同じチャネルで同時にWi-Fiを使用するクライアントとデバイスの数に直接依存します。したがって、直接実現できる実際の最高速度というこの問題は、同じWi-Fiチャネルを使用している人がいない静かな隔離場所に、単一のクライアントデバイスと単一のアクセスポイントを持っていることを意味します。このような状況では、最大速度を決定する要因は次のようになります。

• 使用されるWi-Fiプロトコル(Wi-Fi 5、Wi-Fi 6、...)
• クライアントとアクセスポイントのハードウェア機能（アンテナ数、空間ストリーム数、アクセスポイントのイーサネット接続など）
• 設定（チャネル幅など）

これらの要素を知ることで、ラボ環境で実際に到達できる最大スループットを見積もることができます。

簡単に理解するために、クライアントがレポートするデータレートを確認して、アクセスポイントへの接続を確認します。このデータレートは、テストで証明できる実際のスループットではありません。これは、Wi-Fiが半二重方式のメディアであり、管理オーバーヘッド（フレームに対する確認応答とビーコンの送信が必要）が生じるだけでなく、受信とデコードを向上させるためにフレーム間にショートサイレンスが発生するためです。つまり、データが送信される際には、文書化されたデータレートで送信されますが、データは必ずしも送信されるわけではありません。受信を確実にするため、管理フレームと制御フレームのデータレートははるかに低くなります。実際のスループットテストで使用されるデータレートの65 ～ 70 %の達成を検討できます。たとえば、クライアントが接続され、866 Mbpsでデータが送信されていると報告した場合、実際のテストでは約600 Mbpsの転送速度を報告する必要があります。

使用中の設定パラメータと、関係するデバイスのハードウェア機能がわかっている場合は、達成可能な最大データレート（つまり、このセクションで説明するパーセンテージ計算を使用したスループット）も算出できます。

レポートされるデータレートと達成したいデータレートが一致しない場合は、設定でトラブルシューティングプロセスを開始し、さまざまなパラメータを確認してギャップの場所を把握できます。

たとえば、アクセスポイントモデルC9120が5 GHz帯域で20 MHzのチャネル幅でブロードキャストし、一般的な2空間ストリームのWi-Fi 6クライアントを使用している場合、完全にクリーンなRF（無線周波数）環境では、1台のクライアントで1回のファイル転送で160 ～ 200 Mbpsを実現できると予測できます。

スループットテストおよび検証の詳細については、https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212892-802-11ac-wireless-throughput-testing-and.htmlを参照してください。

基本的なエクスペリエンスの確立

一般的な状況で施設で何が期待できるかを知ることが重要です。技術者が展開のロールアウトの前に空のサイトを訪問し、速度テストを実行し、予想される数を文書化することがよくあります。

その後、従業員や顧客が入ってきて、サイトがビジーになり、実際のエクスペリエンスが大きく異なります。

導入が開始されたら、技術者を派遣して各領域の実際のエクスペリエンスを測定し、平均的な1日のネットワークの状態を記録するのは賢明な考えです。

これには、ネットワークが満足できるレベルで動作しているときの無線あたりのクライアントの平均数と、速度テストで達成された平均スループットが含まれます。

エクスペリエンスの逸脱を探す

ネットワークを運用するときは、突然ダウンする主要なアラートやデバイスを簡単に監視できます。このドキュメントでは、正常に動作しているものの、質の低いエンドユーザエクスペリエンスを提供しているワイヤレスネットワークを特定する方法という、難しい部分に焦点を当てています。

問題の証拠を見つける（受動検査）

ネットワークはテスト済みです。ネットワークは正常に動作し、管理システムとダッシュボードを監視しています。何もダウンとして報告されません：あなたは一歩下がってリラックスすることができます。それとも君は？

エクスペリエンスの低下について不満を言っているエンドユーザからのエコーを待つのは、遅すぎるということでしょう。エンドユーザから苦情が寄せられた場合、問題は長い間続いており、ユーザの声を聞き取れるのは、自分が十分に話を聞き取れる数少ないユーザだけです。

数え切れないほどのユーザがすでに不満を抱いており、あなたやヘルプデスクには何も言っていませんが、ネットワークに悪い評判を与えました。

そこで問題となるのは、体験の質の低さが発生した場合に、どのようにしてすぐに発見できるのかという点です。

1. Cisco Catalyst Centerのクライアント保証ダッシュボード

Cisco Catalyst Center Assuranceダッシュボードには、クライアントの健全性の全体的なグラフがあります。

誰かが間違ったキーを入力したか、デバイスがカバレッジの端に座っているので、正常なクライアントの100%に到達することを望んでいないが、あなたの環境のための正常なクライアントの良い割合に精通していない。

90年代の範囲にいることは、一般に良いニュースです。

非常に簡単な一覧で、正常ではないクライアントに何が起こっているかを確認できます。

• アクセスポイント(AP)から遠く離れていますか。
• 認証の問題ですか。

このグラフで各カテゴリの比率を簡単に確認できます。

同じ範囲のアイデアで、そのページの下部までスクロールして、不良であると報告されたクライアントデバイスをフィルタリングして表示できます。次に、パターンがあるかどうかを調べます。

• これらはすべて2.4 Ghz帯で接続される可能性があります（多くの場合、エクスペリエンスが不十分であることが判明しています）。
• これらはすべて、低い信号強度で報告される可能性があります。
• これらは物理的に同じエリアに存在する可能性があります。

2. Cisco Catalyst Centerのネットワーク保証ダッシュボードとデバイス360

特定の潜在的な問題領域を特定するのに特に有効なメトリックは、Cisco Catalyst CenterのNetwork Assuranceページに移動することです。クライアント数別の上位アクセスポイントを示すウィジェットがあります。

ネットワークの最上位のアクセスポイントに40台のクライアントが接続されている場合は、問題はありません。これは、他のすべてのAP（アクセスポイント）のクライアント数が少ないことを意味します。

一方、上位のAPのクライアント数が異常に多い場合は、クライアントのエクスペリエンスが特に悪いと推測できます（ほとんどのクライアントがスリープ状態で、ネットワーク上でアクティブでない場合を除く）。

次に、「AP単位」の調査に進み、このウィジェットで報告された特定の上位APにズームインして、現在の状態を把握できます。

クライアント数を調べるもう1つの方法は、Catalyst CenterのNetwork Hierarchyページにあるマップに移動することです。フロアビューページで[View Options]をクリックし、[Access Points]セクションで表示を[Assoc]に変更します。Clients」と入力して、APごとのクライアント数を表示します。

MAPテクニックの利点は、クライアント数が多いAPの場所を特定し、その数が正当な値かどうかを評価できることです（特定の時点で、その場所に群集が集まる正当な理由がある場合があります）。

また、ネイバーAPを調べることもできます。ネイバーAPが負荷の一部を共有している場合、状況は良好です。1つのAPのクライアント数が異常に多い一方で、隣接するAPのクライアント数がゼロの場合、より疑わしい状況が発生します。

ネイバーAPに問題がある場合（クライアント数がゼロの場合）、またはRF設計によって、問題のあるAPがネイバーAPに比べてすべてのクライアントを引き付ける可能性があります（たとえば、TX電力が非常に高い、アンテナが異なる場合）。

マップは、各APに関連付けられたクライアントの概要を示します

クライアント数が非常に多い問題のあるAPを特定したら、そのAP名を検索してデバイス360ページを開きます。

ヘルスグラフには、そのAPの健全性が現在は不良であるか、または前日から引き続き不良であったかのどちらかが概要として表示されます。

同じページに、そのAPに関連する問題のリストがあります。この場合、両方の無線で高い使用率が発生していることは明らかです。

イベントビューアを使用すると、そのAPに関連する特定のイベントが発生したかどうかを確認できます。

たとえば、RRMアルゴリズムの設定が頻繁に実行され、チャネルの変更が頻繁に発生して接続クライアントに影響を与える場合や、さまざまな問題や干渉が原因で無線が常にリセットされる場合などです。

デバイス360ページの最後に、ビューを「RF」に設定し、特定の無線を選択し、問題の原因を評価できる興味深い情報を入手できます。

クライアントの数が多いことは必ずしも問題ではありません。クライアントがどの程度有効であるかによって異なります。

クライアントが少ない場合でも、APの処理がビジー状態でエクスペリエンスが低下する場合があります。実際のインジケータはチャネル使用率です。

チャネル使用率が100 %に近づくと（70 %から始まる場合でも）、クライアントは中程度のアクセス、遅延、およびコリジョンを求めて激しい競争を開始します。

このグラフでは、チャネル使用率の合計と、その中での責任のAP部分を比較できます。

たとえば、チャネル使用率が80 %の場合、これはチャネルを介して「誰か」が送信している時間の80 %を意味します。APのRx使用率が40 %、Tx使用率が40 %の場合、このAPだけがチャネルをビジーに保つ役割を持ち（つまり、他のAPは送信を行っていない）、受信と送信の間でバランスが取れていることがわかります。RxとTxを組み合せたAPの使用率がチャネルの使用率から遠い場合は、別のAP（不正または管理対象）が同じチャネルを使用しており、同じチャネルの干渉を引き起こしていることを意味します。

次のスクリーンショットは、チャネルが非常にビジー状態(91 %)のAPを示しています。

このグラフは、この使用率のわずか7 %が他のAPおよび非WiFiソースによるものであり、APが82 %の時間だけ送信をビジー状態で、2 %だけ受信していることを示しています。

クライアントの数と総スループットは、1つ以上のクライアントが大きなファイルをダウンロードしている可能性があることを示します。

干渉グラフを使用すると、チャネルがWi-Fi伝送によってビジー状態のままか、実際の干渉（非Wi-Fi）によってビジー状態のままかを判断できます。

結論として、また経験則として、クライアント数が最も多く、チャネル使用率が最も高いAPを管理する必要があります。次に、この負荷が正当なものかどうか、およびそのエリアのエンドユーザのエクスペリエンスが悪くなるかどうかを評価する必要があります。

3.AI分析

AI分析は、よりインテリジェントなモニタリングを提供します。モニタリングは固定されたしきい値に基づくのではなく、ベースラインの使用状況に適応します。

ネットワークヒートマップでは、クライアント数を変化させることで、1週間で最もクライアント数の多いAPを特定できます。また、クライアントが接続されていないAPを簡単に特定することもできます。逆の問題もあります。

これらのAPには物理的な問題（取り付けの問題、アンテナの問題など）があるか、無線がフリーズしている場合（およびそのAPをリブートすると解決する場合）はソフトウェアの問題である可能性があります。

Trends and Insightsページには、チャネル使用率またはクライアントアクティビティが高い状態を定期的に示すAPのリストが表示されるため、これが最も混雑しているエリアに一致するかどうか、または異常な点が存在するかどうかを簡単にクロスチェックできます。

インフラストラクチャのアクティブなテスト

ユーザが特定のエリアでエクスペリエンスが低いと報告した場合は、積極的にテストしてフィードバックを確認します。一般的なテストは、実際のクライアントトラフィックとは大きく異なることを理解することが重要です。

ユーザは通常、自分の好きなアプリケーションを使用しようとしますが、動作すれば満足です。サイズの大きいファイルを転送することはほとんどありません。お気に入りのアプリケーションの動作は異なる可能性があります。

• オンデマンドビデオ：任意の量の帯域幅を消費する可能性があります（ビデオが720pまたは4Kのいずれであるかによって異なります）。
  • ビデオは数秒または数分前にバッファリングされるため、ジッタに対する耐性が非常に高くなります。このパターンは、短い期間の大きなファイル転送のように見え、次のプリロードが発生するまでビデオがバッファから再生される間、無音になります。
• 音声コール：これは帯域幅をほとんど消費しませんが、遅延とジッタの影響を非常に受けやすいものです。
  • これは、QoS(Quality of Service)タギングを使用する可能性があるため、ベストエフォートトラフィックとは異なる（優先順位が付けられた）エクスペリエンスに直面します。
• データ：ソーシャルメディアアプリケーションは、バーストごとにデータをダウンロードします。
  • 量は、コンテンツとユーザがスクロールする速度によって異なります。

一般的なスループットテストアプリケーションでは、可能な限り高い転送速度を実現するためにプロトコルを最大化します。つまり、メディアを予約し、可能な限り多くのデータフレームを連結して送信しようとします。これは、本質的に非常にバースト性の高い実際のアプリケーション（ファイル転送以外）と同じ使用タイプを表しているわけではありません。

実際のアプリケーションをテストすると、ユーザの動作を模倣できますが、実際のメトリックや数値を比較することは不可能です。ネットワークがスムーズな場合でもスムーズでない場合でも、主観的な感覚が得られます。

スループットのテストでは、多くのWebサイトが一般的です。クライアントとインターネット間の帯域幅全体をテストする際に、エンドユーザのエクスペリエンスを適切に把握できます。ただし、インターネット接続やルーティングおよびファイアウォールの問題とは別にワイヤレスネットワークを検証する場合は、Iperf(https://community.cisco.com/t5/wireless-mobility-knowledge-base/iperf-test-for-measuring-the-throughput-speed-of-a-wlan-client/ta-p/3142047)などの専用のスループットテストツールを使用することをお勧めします。

このツールを使用すると、ネットワーク内に配置したクライアントとサーバの間で特定のテストを行うことができます。これにより、サーバをネットワーク内の特定の場所に移動し、長いネットワークセクションと長いネットワークセクションのスループットをテストして、各セクションを検証できます。最初に、ワイヤレスクライアントがローカルスイッチングまたはファブリック対応のワイヤレスの場合は、APと同じスイッチにIperfサーバを配置します。または、中央スイッチングの場合は、WLC（ワイヤレスLANコントローラ）と同じスイッチ（可能であればクライアントVLAN）にIperfサーバを配置します。

アンカーWLCを使用している場合、Iperfサーバは、トラフィックが終端されるアンカーWLCと同じスイッチに配置する必要があります。非アンカーWLAN（ワイヤレスLAN）を作成して、期待を裏切る可能性があるスループットの結果が、アンカー自体と非アンカーWLANのどちらが原因であるかを確認するのは、興味深いことがあります。

複数のクライアントを使用して同時にスループットテストを行うことは、あまり意味がありません。スループットテストでは、この単一のクライアントが使用可能なチャネルの通信時間をすべて使用することが想定されます。したがって、2つのクライアントが同時にスループットテストを実行すると、結果が少なくとも半分に分割されます。使用するクライアントの数が増えると、コリジョンの発生数が増え始め、その結果は典型的なものではなくなります。

ネットワークテストを自動化する複数の^サードパーティツールがあります。1つのエリアでスループットをテストしている間、テストの間はすべての通信時間を効果的に使用していることに注意してください。その場合、他のクライアントに悪影響を及ぼすため、ネットワークを頻繁にテストすることは好ましくありません。

スループット問題のトラブルシューティング

スループットの問題を特定する際には、問題を切り分けるために次の点を確認できます。

• テストを開始する前に、RF環境がすでにビジー状態かどうかを特定します。チャネル使用率が（テストの範囲外で）高いほど、スループットテストの結果は低くなります。チャネル使用率の問題が見つかった場合は、同じチャネルの同じエリアに他のAPが存在するかどうかを確認し、RF設計を再検討します。チャネル幅を狭め、不正を排除し、より焦点を絞ったカバレッジで異なるアンテナを使用することが、すべての優れた選択肢です。APを追加することが常に最善の方法とは限りません。
• スループットテストのOver-The-Air(OTA)キャプチャを取得し、802.11レイヤでのデータ再試行が多いかどうかを確認します（全データフレームの割合）。再試行回数が多い場合は、RF環境に問題がある可能性があります。また、使用されているデータレート、最適でない可能性のあるプロトコル、または空間ストリームの数も確認します。Over-the-Airキャプチャでは、大規模なデータ転送が非常に特徴的です。同じ送信元と宛先を持ち、互いのデルタ時間が非常に短い数十のデータフレームが表示され、その後にブロックACKが続きます。各データフレームの後の通常のACK、または大量のRequest-to-Send/Clear-to-Sendによって転送が特徴付けられる場合は、スループットが低いことを簡単に説明できます。
• スループットの問題がWLANのすべてのセキュリティタイプで発生するかどうかを確認します。クライアントとAPの間の特定のセキュリティの非互換性がスループットの低下につながる場合があります。