【実務・中級編】 IEEE 802.11ax (Wi-Fi 6) のOFDMAによる周波数利用効率の最適化 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは。現場の第一線でネットワークやインフラの設計に携わっていると、「なぜかオフィスの無線環境が重い」「多数のIoTデバイスが同時にデータをプッシュすると、APIのレスポンスが跳ね上がる」といった相談を本当によく受けます。

回線事業者からどれだけ太い光回線を引き込もうとも、最後の1ホップであるWi-Fi空間が「旧時代の満員電車」のような状態であれば、Webアプリケーションのパフォーマンスチューニングも意味をなさなくなってしまいます。

そこで今回は、Wi-Fi 6（IEEE 802.11ax）の最大の発明であり、高密度環境におけるパケットの詰まりを劇的に解消した「OFDMA（直交周波数分割多元接続）」に焦点を当てます。教科書的な仕様のなぞりではなく、実際のパケットがどのように空中を飛び交い、私たちのインフラにどう恩恵をもたらしているのか、シニアエンジニアの視点で深掘りしていきましょう。

—

1. なぜ従来のWi-Fiは「高密度環境」に弱かったのか？

これまでのWi-Fi（Wi-Fi 5 / IEEE 802.11acまで）の通信を思い返してみてください。基本技術として使われていたのは OFDM（直交周波数分割多重） です。

OFDMは非常に優れた技術ですが、根本的な弱点がありました。それは「1回の通信スロット（タイミング）において、1台の端末がチャネル（20MHzや40MHzなど）の全帯域を独占する」という設計思想です。

例えば、オフィスの一角で以下のような状況が起きていたとします。

  • スマートフォンが数キロバイトの小さなJSONデータをAPIにPOSTしている
  • 隣のPCでは、数ギガバイトのログファイルをクラウドストレージにアップロードしている

旧規格（OFDM）の世界では、たった数バイトのJSONを送りたいだけのスマートフォンであっても、そのチャネルの権利を掴むと、帯域全体をその子機のために一時的に占有してしまいます。例えるなら、「消しゴム1個を運ぶために、2トントラックを1台丸ごとチャーターしている」ようなもので、圧倒的な帯域の無駄遣い（パケットのフラグメンテーションや待機時間の発生）が生じていました。これが、カフェやオフィス、スマートホームのように数十台のデバイスがひしめく高密度環境で遅延（レイテンシ）が跳ね上がる根本原因です。

—

2. Wi-Fi 6の切り札「OFDMA」のメカニズム

この非効率を根底から覆したのが、Wi-Fi 6で導入された OFDMA（Orthogonal Frequency Division Multiple Access） です。

サブキャリアの分割と「リソースユニット（RU）」

OFDMAでは、利用可能なチャネル（20MHz、40MHzなど）をさらに細かな周波数ブロックに分割します。この分割された最小単位を RU（Resource Unit：リソースユニット） と呼びます。

Wi-Fi 6の20MHzチャネルを例に取ると、次のような細かなRUに分割されます。

  • 26トーンRU（最大9ユーザーを収容可能）
  • 52トーンRU（最大4ユーザーを収容可能）
  • 106トーンRU（最大2ユーザーを収容可能）
  • 242トーンRU（単一ユーザー用）

アクセスポイント（AP）は、このRUを巧みに切り分け、「小さなパケットを投げるデバイスには26トーンのRUを割り当て、重いデータを送るデバイスには大きなRUを割り当てる」という動的な交通整理を、1回の無線フレーム（ダウンリンク/アップリンク）の送信タイミングで同時に行えるようになりました。

双方向（DL/UL）のOFDMA

さらに重要なのは、これが下り（DL: ダウンリンク）だけでなく、上り（UL: アップリンク）方向でも適用される点です。
AP側が主導権を握り、複数台の端末に対して「今からこのタイミングで、指定された周波数（RU）を使って一斉にパケットを送信せよ」というトリガーフレームを送り出します。これにより、これまで上り通信で頻発していたパケットの衝突（コンテンション）が劇的に減少し、スループットと遅延の安定性が劇的に向上しました。

—

3. 通信フローから読み解くOFDMAのリアル

実際の無線空間で、APとクライアント端末（STA）がどのようにハンドシェイクを行い、OFDMAによる効率的なパケット送受信を行っているのか、そのシーケンスを紐解いてみましょう。

[アクセスポイント (AP)]              [クライアント A (小容量)]   [クライアント B (大容量)]
         |                                    |                           |
         | --- (1) トリガーフレーム (UL-MU) ---> |                           |
         |     (RU割当: 26トーン)             |                           |
         | --- (RU割当: 106トーン) ----------> |                           |
         |                                    |                           |
         | <--- (2) 同時データ送信 (A-MPDU) --- |                           |
         | <--------------------------------- | ------------------------- |
         |                                    |                           |
         | --- (3) ブロードキャスト/マルチBA -> |                           |
         |     (Block ACKを一括返送)           |                           |
         |                                    |                           |

1. トリガーフレームの送信（Trigger Frame）
APは、現在接続している複数のクライアントのバッファ状況（QoSの状態など）を把握し、どのクライアントにどの周波数ブロック（RU）を割り当てるかを記した制御パケット（Trigger Frame）を空中に放ちます。
2. アップリンクの同時送信（UL OFDMA）
指示を受けたクライアントAとBは、指定された正確な周波数帯とタイミングで、ミリ秒単位のズレもなく一斉にデータをAPに向けて送信します。周波数が物理的に分かれているため、電波干渉や衝突が起きません。
3. ブロック確認応答（Multi-STA Block Ack）
APは受信した複数のデータに対して、一括して確認応答（Block ACK）を返します。

この一連のハンドシェイクにより、無線パケットのオーバーヘッドが最小化され、多数のIoTデバイスやスマホが繋がる環境であっても、安定した低遅延（低レイテンシ）なAPI通信の基盤が維持されます。

—

4. 実務で活かすWi-Fi 6 / ルーター設定の勘所

ネットワークエンジニアやインフラ担当者が現場でWi-Fi 6の恩恵を最大限に引き出すために、ルーターやアクセスポイント（Cisco Catalyst、Aruba、Yamaha、あるいはハイエンドなコンシューマー/Prosumer向け機器）を設定・検証する際の重要なポイントをいくつか共有します。

設定値・パラメータのチェックリスト

1. ヘルスチェック時の検証スクリプト（Pythonによる遅延計測の例）
高密度なWi-Fi環境下におけるAPIの往復遅延（RTT）をモニタリングし、OFDMAやMU-MIMOが正しく機能しているか（輻輳によるスパイクが起きていないか）を確認するためのシンプルなPythonスクリプトです。

import time
import requests
from requests.exceptions import RequestException

# 検証用ローカルAPIのエンドポイント
API_ENDPOINT = "http://192.168.1.100/api/v1/health"
REQUEST_COUNT = 50

def measure_latency():
    latencies = []
    print(f"[*] Starting latency test against {API_ENDPOINT} ({REQUEST_COUNT} requests)...")
    
    for i in range(REQUEST_COUNT):
        start_time = time.time()
        try:
            # タイムアウトを短めに設定し、無線空間の詰まりを検知しやすくする
            response = requests.get(API_ENDPOINT, timeout=2.0)
            elapsed = (time.time() - start_time) * 1000  # ミリ秒に変換
            
            if response.status_code == 200:
                latencies.append(elapsed)
            else:
                print(f"[-] Request {i+1} failed with status: {response.status_code}")
                
        except RequestException as e:
            print(f"[-] Request {i+1} error: {e}")
            
        # 実際のIoTデバイスのポーリング間隔を模して少しウェイトを入れる
        time.sleep(0.1)

    if latencies:
        avg_latency = sum(latencies) / len(latencies)
        max_latency = max(latencies)
        min_latency = min(latencies)
        print("\n--- Test Results ---")
        print(f"Successful requests: {len(latencies)}/{REQUEST_COUNT}")
        print(f"Min Latency: {min_latency:.2f} ms")
        print(f"Max Latency: {max_latency:.2f} ms")
        print(f"Avg Latency: {avg_latency:.2f} ms")

if __name__ == "__main__":
    measure_latency()

2. AP側の無線パラメータ調整のTips

  • OFDMAの有効化（DL/UL双方）: メーカー製APによってはデフォルトで有効になっていますが、レガシー機器との互換性モード（Legacy Mode）が有効になっているとOFDMAが無効化されるケースがあります。必ず「802.11ax専用機能（High Efficiency）」が有効になっていることを確認してください。
  • チャンネル幅（Channel Width）の選定:

オフィスの高密度環境では、あえてチャネル幅を20MHzまたは40MHzに固定することを強く推奨します。80MHzや160MHzといった広帯域は理論上のスループットは上がりますが、電波干渉（隣接チャネルノイズ）の影響を受けやすく、かえってOFDMAのメリットを相殺してしまうジレンマがあります。「太いパイプを一本通すより、細いパイプで確実に整理して流す」のが高密度環境の鉄則です。

  • TWT（Target Wake Time）の併用:

IoTデバイス向けには、OFDMAとセットでTWTを有効にしましょう。デバイスがAPと「何秒の何ミリ秒に起きて通信するか」をあらかじめネゴシエーションするため、スリープ時間を最大化しつつ、混雑を回避した効率的なOFDMA通信が可能になります。

—

5. まとめ

今回はWi-Fi 6の根幹技術であるOFDMAについて、その物理層・MAC層の挙動から実務的なエンジニアリングの視点まで解説しました。

「たかが無線、されど無線」。アプリケーションレイヤーでどれだけクエリを最適化し、APIのレスポンスを数ミリ秒削り出しても、その下層にあるWi-Fi空間でパケットの衝突や非効率な帯域占有が起きていては、エンドユーザーが体感するパフォーマンスは改善しません。

無線規格の進化の本質は、単なる「最高速度（理論値）のインフレ」ではなく、「過酷な電波環境や高密度なトラフィックの中でも、遅延を最小限に抑えてパケットを確実にデリバリーする仕組みの洗練」にあります。

ぜひ、皆さんの現場のアクセスポイントの設定や、スマートホーム/オフィスのネットワーク設計を見直す際の参考にしてみてください。パケットの流れる音が聞こえるような、クリアで快適なネットワーク環境を手に入れましょう！

スポンサーリンク

コメント

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