【テクニカル・上級編】 Wi-Fiサイトサーベイの実施手順とヒートマップ作成(予測サーベイ vs 実測サーベイ) – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

電波は見えない、しかし論理は見える:Wi-Fiサイトサーベイから始めるインフラの極限最適化

Wi-Fi 7(IEEE 802.11be)の時代、マルチリンクオペレーション(MLO)がもたらす低遅延の世界に酔いしれる前に、一度立ち止まって「物理層(PHY)」の現実を見つめ直すべきだ。どれほど洗練されたプロトコルスタックも、電波という不安定なメディアの上では、SNR(信号対雑音比)という冷徹な物理法則に従うしかない。

今回は、単なる「繋がるWi-Fi」を超え、高負荷なIoT環境やクリティカルなインフラを構築するエンジニアのために、サイトサーベイの本質と、その先のトランスポート層のチューニングまでを深掘りする。

—

予測サーベイ(Predictive Survey):物理的制約の事前モデル化

導入前の「予測サーベイ」を単なる壁の配置図と侮ってはいけない。電波の減衰係数(特に5GHz/6GHz帯における遮蔽物の影響)を正確に計算し、AP(アクセスポイント)の配置を決定するプロセスは、OSI参照モデルの最下層におけるチューニングだ。

予測サーベイで重視すべきは、単なる受信信号強度(RSSI)の-65dBm以上の確保ではない。「チャネル間干渉の最小化」と「CCI(同チャネル干渉)の制御」こそが、パケット再送率を左右する。

シミュレーションにおける考慮事項

  • 壁の材質定義: コンクリート、金属、家具による減衰値を正確に設定せよ。特に6GHz帯は回折性が低く、壁一枚が通信を断絶させる壁になる。
  • クライアント能力の逆算: 最も弱いクライアント(IoTデバイス等)の送信出力を基準に、アップリンクのバジェットを設計する。

—

実測サーベイ(Post-Deployment Survey):パケットの「泥」を拾う

ヒートマップはあくまで理想図だ。実測サーベイの本質は、現場で実際にクライアントがどの程度のパケットロス、そして再送を行っているかを観測することにある。

特に、802.11フレームの管理フレーム(BeaconやProbe Request)の密度を解析し、エアタイムが「隠れ端末問題」や「低速データレートの維持」によって浪費されていないかを検証する。

実測時に確認すべきKPI

1. SNR (Signal-to-Noise Ratio): 25dB以上を維持。これ以下ではMCSインデックスが下がり、効率的な変調方式(QAM)が使えず、スループットが劇的に低下する。
2. パケット再送率: 10%を超える場合は、物理的な障害か、周囲の電波環境による飽和を疑え。
3. RSSIの対称性: APからの信号は強くても、端末からのACKが届いていないケースが多い。これを「リンクバジェットの非対称性」と呼ぶ。

—

ネットワーク層からトランスポート層への最適化

Wi-Fi環境が整ったら、次に行うべきはパケットの「詰め込み」と「ハンドシェイクの加速」だ。

1. TCPバッファとウィンドウサイズの最適化

高遅延・高ロスになりがちなWi-Fi環境では、LinuxカーネルのTCPスタックをチューニングし、BDP(Bandwidth Delay Product)を適切に定義する。

# /etc/sysctl.conf への追記例
# ネットワーク帯域が広く、遅延が変動しやすいWi-Fi環境用
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# BBR混雑制御アルゴリズムの採用(パケットロスに強い)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

BBR(Bottleneck Bandwidth and Round-trip propagation time)は、Wi-Fiのような変動の激しいリンクにおいて、パケットロスを「混雑」と誤認してCWND(輻輳ウィンドウ)を急激に絞るリスクを回避してくれる。

2. TLSハンドシェイクの最適化

Wi-Fiの不安定な環境下では、TCPの3ウェイハンドシェイクに加え、TLSのハンドシェイクでRTT(往復時間)を消費することは致命的だ。TLS 1.3の採用は必須条件であり、0-RTT(Early Data)の活用を検討すべきだ。

# Nginxの設定例:TLS 1.3によるハンドシェイク高速化
ssl_protocols TLSv1.3;
ssl_early_data on; # 0-RTTの有効化
# ただしリプレイ攻撃への対策として、アプリケーション層での冪等性確保が必須

—

脆弱性回避と「見えない」攻撃への対策

最後に、セキュリティの話をしよう。Wi-Fiのセキュリティは WPA3 で強化されたが、インフラ設計者として意識すべきは「フレーム注入」や「不正なAPへの誘導」だ。

  • PMF (Protected Management Frames) の強制: Wi-Fi 6/7では必須だが、古いクライアントが混在する場合に無効化してはならない。管理フレームを暗号化できない環境は、即座にDoS攻撃の標的となる。
  • ヘッダー圧縮とセキュリティ: ROHC(Robust Header Compression)が有効な環境では、VoIP等のパケットヘッダーを極限まで圧縮するが、その際のパケットインスペクション(IDS/IPS)のバイパスには注意が必要だ。

結びに:エンジニアの誇り

Wi-Fi設計は、無線という「制御不能な媒体」を、いかにして「決定論的なシステム」に近づけるかという知的格闘技だ。ヒートマップの色が綺麗に揃うこと以上に、tcpdump でキャプチャしたパケットの再送フラグが静寂を保っていることこそが、我々インフラアーキテクトにとっての最高の報酬である。

計測を怠るな。そして、パケットが物理層のノイズを突き抜けて、アプリケーション層で正しくデコードされるその瞬間まで、妥協なきチューニングを続けてほしい。

コメント

タイトルとURLをコピーしました