【実務・中級編】 IEEE 802.11n (Wi-Fi 4) の物理層とMIMO技術 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

Wi-Fi 4(IEEE 802.11n)が変えた無線空間:MIMOと空間多重化の物理的実態

ネットワークエンジニアとして現場に立っていると、いまだに古いオフィスや工場の一隅で、しぶとく稼働し続けるIEEE 802.11n(Wi-Fi 4)の機器に出会うことがあります。最新のWi-Fi 7が喧伝される今、「何をいまさら古い規格を」と思われるかもしれません。しかし、現在の高速無線LANの基礎――すなわち、電波の反射波を敵ではなく味方につけ、複数のアンテナで同時にデータを送り出すというパラダイムシフトを成し遂げたのは、まぎれもなくこのWi-Fi 4です。

Web APIの設計やクラウドインフラの構築に日夜奔走するエンジニアの皆さんにとって、無線区間(レイヤー1およびレイヤー2)の挙動は「ブラックボックス」になりがちです。「なぜか特定のAPIリクエストだけタイムアウトする」「JSONのペイロードが大きくなると途端にスループットが落ちる」といったトラブルに直面したとき、その原因が実はオフィスの隅にある古いアクセスポイントのマルチパス干渉や、MIMOのフォールバックにあるとしたらどうでしょう。

今回は、Wi-Fi 4で導入されたMIMO(Multiple-Input and Multiple-Output)の基本概念と、それが物理層でどのように空間を支配しているのかを、現場のシニアエンジニアの視点から紐解いていきます。

—

1. 11n以前の絶望:マルチパス干渉という名の悪夢

Wi-Fi 4が登場する前、IEEE 802.11a/b/gの時代における無線通信は、常に「反射波(マルチパス)」との戦いでした。

電波は目に見えない空間を直進しますが、オフィスのコンクリート壁、スチール机、天井の配管などに当たると反射します。送信機から出た電波が、直接届く波(直射波)と、壁で何度も反射して遅れて届く波(反射波)として受信機に到達すると、これらが互いに干渉し合います。これを「マルチパス干渉」と呼びます。

古い規格では、この反射波は「データの破損を引き起こすノイズ」でしかありませんでした。そのため、マルチパスが多い環境では、通信速度を思い切り落とし(低次変調へのフォールバック)、確実に届く速度で通信せざるを得なかったのです。

「反射波を悪者から味方へ」転換したMIMO

Wi-Fi 4(IEEE 802.11n)はこの常識を180度ひっくり返しました。「反射して届くなら、その反射経路(パス)ごとに別のデータを載せてしまえばいいじゃないか」――これがMIMOの思想の根底にあります。

マルチパスが多い複雑な電波環境こそ、MIMOにとっては最高のステージとなります。障害物が多いオフィスのほうが、空間多重化の恩恵を受けやすいというのは、ネットワークエンジニアとしては非常に興味深いパラドックスです。

—

2. MIMOの基本概念と空間多重化(Spatial Multiplexing)の仕組み

MIMOを支える技術要素はいくつかありますが、スループットの飛躍的な向上に最も寄与しているのが「空間多重化(Spatial Multiplexing: SM)」です。

物理層におけるアンテナ構成の表記

スペック表で 3x3:3 のような表記を見たことがあるでしょう。これは左から順に以下のパラメータを意味しています。

  • 送信アンテナ数(Transmit Antennas)
  • 受信アンテナ数(Receive Antennas)
  • 最大空間ストリーム数(Spatial Streams)

例えば、Wi-Fi 4のルーターで一般的な 2x2:2 構成であれば、送信側が2本のアンテナから異なるデータを同時に射出し、受信側の2本のアンテナでそれぞれを受信・分離します。周波数帯域幅(チャンネル幅)を従来の 20MHz から 40MHz へ倍増させる技術(Channel Bonding)と組み合わせることで、理論上の最大通信速度は 300 Mbps(さらには一部の独自拡張で 450 Mbps や 600 Mbps)へと跳ね上がりました。

チャネル行列とCSI(Channel State Information)

数学的な裏側を少しだけ覗いてみましょう。送信側のアンテナベクトルを $\mathbf{s}$、受信側のアンテナベクトルを $\mathbf{r}$、空間の伝搬特性(チャネル特性)を表す行列を $\mathbf{H}$、雑音を $\mathbf{n}$ とすると、受信信号は以下の線形方程式で表されます。

$$\mathbf{r} = \mathbf{H}\mathbf{s} + \mathbf{n}$$

受信側(クライアントのWi-Fiチップ)は、送信側から送られる既知のトレーニング信号(プリアンブル)を元に、このチャネル行列 $\mathbf{H}$ を推定します。これをCSI(Channel State Information)の取得と呼びます。

受信側はこの $\mathbf{H}$ の逆行列(あるいはそれに類するアルゴリズム、例えばZF法やMMSE法など)を計算し、ごちゃ混ぜになって届いた電波の合成波から、元の独立したデータストリーム $\mathbf{s}_1, \mathbf{s}_2$ を見事に分離・復元するのです。この高度な信号処理を、わずか数マイクロ秒の単位でパケットごとにハードウェア(ベースバンドチップ)がリアルタイムに処理しています。

—

3. インフラ運用・開発現場での実務的Tips:無線環境のデバッグ

Webアプリケーションを開発し、社内検証用のCI/CDサーバーやIoTゲートウェイを無線LANで接続する際、このWi-Fi 4のMIMO挙動がトラブルの火種になることがあります。現場でよくある失敗と対策を共有しておきます。

トラブル事例:なぜか特定のLinux端末だけスループットが出ない

ある組込みLinuxベースのIoTゲートウェイを導入した際、近くにあるMacBookは 300 Mbps でリンクしているのに、そのIoT端末だけが 65 Mbps(MCS 7、シングルストリーム、20MHz幅)で頭打ちになる現象が発生しました。

原因を調査すると、そのIoT端末の無線モジュール(Wi-Fiチップ)のドライバー設定に問題がありました。

1. アンテナの物理結線ミス(2本あるはずの端子の片方が基板上で未接続、あるいはMHFコネクタが外れかけていた)。
2. ドライバー側で ht_capab(High Throughput Capabilities)のパラメータが制限され、STBC(Space-Time Block Coding)や Short GI(Guard Interval)が無効化されていた。

現場で確認すべき主要な無線パラメータ

Linux環境(hostapd や wpa_supplicant、あるいはクライアント側の iw コマンド)で、Wi-Fi 4のリンク状態を確認・デバッグする際によく使うコマンドラインの例を挙げていきます。

# 現在接続しているWi-Fiインターフェース(例: wlan0)の詳細なリンク情報を取得
iw dev wlan0 link

出力結果の中に、以下のような項目が現れます。

  • tx bitrate: 現在の送信速度(例: 144.4 MBit/s MCS 15 40MHz)
  • MCS (Modulation and Coding Scheme): 変調方式と符号化率のインデックス

ここで MCS 8 から MCS 15 あたり(2ストリーム使用)が出ていれば、正常にMIMO(空間多重化)が機能しています。もし MCS 0 から MCS 7 の間で固定されている、あるいは極端に低いレート落ちしている場合は、以下のデバッグ手順を踏みます。

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

1. 電波環境の可視化(スペクトラムアナライザやWi-Fiアナライザの活用)

  • 周囲の干渉波(電子レンジ、近隣の強力なAPの同チャネル干渉)により、CSIの推定精度が極端に落ち、APが自動的にストリーム数を絞っている(フォールバックしている)可能性を疑います。

2. ドライバーの設定確認(iwconfig や iw)

  • 意図せず省電力モード(Power Saving Mode)が有効になっており、省電力のためにシングルストリームに落とされていないか確認します。

3. パケットキャプチャによるフレーム解析

  • モニターモードに入れた別のLinux機で tcpdump や Wireshark を使い、Beacon フレームや Association Request/Response の HT Capabilities 要素を覗きます。相手のデバイスがどの程度のMIMOストリームを広告(Advertise)しているかを正確に把握できます。

—

4. アプリケーション層への波及:なぜネットワーク層を知る必要があるのか

「自分はバックエンドのAPIサーバーやフロントエンドのコードを書いているから、無線レイヤーのMIMOなんて関係ない」と思っていませんか?

しかし、考えてみてください。APIから返される数メガバイトのJSONレスポンスや、マルチパートでアップロードされるバイナリデータは、最終的にこのシリアライズされた電波の空間(物理層)をパケット単位で通過していきます。

もし無線区間でマルチパス干渉やストリームの切り替え(Rate Adaptation)が頻発していると、無線区間でのフレームロス(再送)が増加します。TCPは輻輳制御アルゴリズムにより、パケットロスを「ネットワークの混雑」と誤認し、ウィンドウサイズを縮小させます。結果として、APIのレスポンスタイム(TTFBや完了までのレイテンシ)が致命的に悪化するという現象が起きます。

インフラエンジニアやWebエンジニアであっても、ハードウェアに近い物理層の仕様(Wi-Fi 4のMIMOがどうやって空間を分けているかなど)を頭の片隅に入れておくことで、「なぜこの拠点のAPI通信だけ体感速度が遅いのか」という問いに対して、レイヤー1からレイヤー7までを貫く一貫した仮説検証ができるようになります。

—

おわりに

Wi-Fi 4(IEEE 802.11n)が切り拓いたMIMOという技術は、単なる「速度を上げるための機能」ではありません。それは、厄介な障害物や反射波を「利用価値のあるリソース」へと昇華させた、通信工学における美しいアーキテクチャの勝利です。

最新のWi-Fi 6 / 6E、そしてWi-Fi 7へと進むにつれて、OFDMAや4096-QAMといったさらに高度な技術が積み重なっていますが、その土台にある「複数のアンテナで空間を支配する」という基本思想は、このWi-Fi 4の時代から何一つ変わっていません。

現場で泥臭いトラブルに直面したとき、ぜひこの記事で解説した物理層の挙動や、空間多重化の仕組みを思い出してみてください。パケットが目に見えない空間をどのように駆け抜けているのかを想像できるようになれば、あなたのエンジニアとしての視野は、より一層深く、強固なものになるはずです。

コメント

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