無線LANのチャンネルが被っているから遅いのでは？という素朴な疑問を検証した

新年あけましておめでとうございます。
キャプチャ装置を作ったり、パケットを解析したりして暮らしている黒ブラと申します。
無線LANのトラブルシューティング用に新しいパケットキャプチャ装置（Airman）を作ったのでデモを兼ねて動かしてみることにします。
ただ流れているパケットを追っても面白くないので、無線LANのトラブルシューティングでよくある、「他のSSIDが同じチャンネルにいるから遅いのでは？」という疑問を検証して考察します。
対象読者想定は企業の情シス担当者です。

よくある疑問

無線LANを扱う指南書には空いている無線チャンネルを使え的な事が書いてあったりするわけですが、なかなか空いているチャンネルがなく、大丈夫かなと思いつつ、おっかなびっくりご近所様と重複したチャンネルを使わざるを得なかったりする今日この頃、皆様いかがお過ごしでしょうか。
無線LANが遅い、ブチブチ切れるといったクレームが寄せられた日には電波モニタリングツールとにらめっこしつつ、「コレ電波強度がマイナスってことは数字が小さい方が強いの？」みたいな初めてプレイするカードゲームのルールを確認してしまう感じのムーブをしてしまうのはあるあるかと思います。
本記事にて無線LANにおける実際のパケットを分析する過程と、ちょっとした勘所をお伝えできればと思います。

試験環境

無線LAN端末と無線LANルータを2台ずつ用意し、ジャミング用とテスト用に分けます。
同じ電波チャンネルで、無負荷のトラフィックとジャミングありのトラフィックを2パターン流し、弊社が開発中の新型パケットキャプチャ装置（Airman）にて電波と有線のパケットを同時に採集して分析します。
ジャミングありとなしでどの程度の差が出るものなのかを検証します。
WANの遅延やパケロスの影響を除外するためクローズドなLAN環境を用意しました。

概要図

無線LAN環境とトラフィックの詳細

無線LANの電波チャンネルはご近所様のアクセスポイント状況から4を固定で選択、20MHz幅で流します。
流すトラフィックは巨大ファイルの転送をTCP単一コネクションで流し、再送等の遅延要因を評価していきます。
テストトラフィックには500MB程度のファイル転送、ジャミングには同様に倍の1GB程度のトラフィックを当てて、どの程度通信遅延が発生するかを見ます。
SSIDは下記の通り、両方とも電波強度はギンギンです。
余談ですが、この手の電波モニタリングツールは電波チャネルを数秒ごとに切り替えながらビーコンフレームを拾い、その電波強度を表示する仕組みになっているため、負荷をかけてガチで邪魔されたときにトラフィックがどうなるか判断するには情報の解像度が足りません。

Chバチ被り

計測結果

テストトラフィック（500MB）を流しきるまでの時間

• 負荷なし　　　102秒

• 負荷あり　　　164秒

負荷ありでも、実務上劇的に変わらないのではないかと思われる結果が出ました。
時間の計測はパケットキャプチャを用いていますので正確です。

負荷なし

負荷あり（青が負荷）

トラフィックのI/Oは上記のようなグラフになりました。（縦軸はByteなので注意）
バチバチに負荷がかかっていても赤のテストトラフィックはそれなりに速度が出ているように思えます。
テストとジャミングのトラフィックはMACアドレスのフィルタで分けています。

有線パートの評価

有線パートのTCP品質を評価します。
Wiresharkのエキスパート分析で出てくる再送件数を全体のパケット数で割ります。純粋な転送効率を求めるため、単一のTCPコネクションとなるよう、生のトラフィックをフィルタし、下処理を行っています。

有線再送数の評価（負荷なし）

負荷なしのパターンでは有線パートの再送率は7.9％（Excelで計算しました）

有線再送数の評価（負荷あり）

負荷ありのパターンでは有線パートの再送率は9.3％になりました。

無線パートの評価

有線パートの再送率には無線パートの通信効率が加味されていると考えられます。
電波のキャプチャで取得した無線パケットの品質を評価します。

無線再送数の評価（負荷なし）

負荷なしのパターンでは無線パートの再送率は4.8％
これはIEEE802.11フレームの再送フラグの数を数えています。

無線再送数の評価（負荷あり）

負荷ありのパターンでは無線パートの再送率は7.1％となりました。

総括

お仕事ではもうちょっと細かいところまでレポートするのですが、結論として「チャンネルが被ってトラフィックがバシバシ流れてもそんなに遅くはならない」ということが分かった感じですね。
負荷ありでも30Mbps、負荷なしで50Mbpsくらいがアベレージで出る感じでした。（周波数帯を狭く絞っていることと一般的な実効速度を考慮すると11nで50Mbpsはそんなもんかなと言う気がします。）
この結果を踏まえて、巷でよく言われているところの、ご近所のSSIDと電波チャンネルが重複していることが無線LAN不調の原因だと安易に推測するのは早計かもしれません。
補足として、TCPコネクションの再送率として、負荷ありパターンの9.3%はちょっと多い気もしますが、詳細にチェックしたところそれほど全体の足を引っ張っていなかったので、速度への影響は多くないと見ました。
500MBのダウンロードが約2分半であればユーザーから文句が来ないレベルかと思います。

最後に

ネットワークの遅延に関するクレームにおいて、初手で把握するべきは「具体的にどの操作（処理）が何秒かかったのか」です。
我慢できないほど遅くて業務に支障が出ているのに、ゆっくり対応されたらユーザーの怒りのボルテージが急激に上昇し、信頼を失いかねません。
正確にユーザーレスポンスを計測し、業務影響を見極める必要があります。そしてその後の報告や優先順位の検討などすべての判断に、正確なレスポンスデータが生きてきます。
数値をもとに、ユーザーやサポートベンダーを含めたステークホルダーとコミュニケーションし、解決までのプロセスを説明可能な状態に保つことが大切ではないかと考えています。