【実務・中級編】 Wi-FiにおけるQoS (WMM) の優先制御クラス – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは。長年、数々のネットワークの修羅場をくぐり抜けてきたシニアエンジニアの私だ。

オフィスビルから個人の書斎まで、今や私たちの生活は「見えない電波」であるWi-Fiなしには成立しない。新しいスマホを買い、高速な光回線を引き、「よし、これで爆速だ！」と意気込んだものの、なぜかオンライン会議中に自分の声だけが途切れたり、4Kの動画配信が突然カクついたりした経験はないだろうか？

「ルーターの性能は十分なはずなのに、なぜ？」

その答えの多くは、実は電波の出力不足ではなく、「電波の交通整理（QoS）」の失敗にある。パケットという名の小さな旅人たちが、限られた無線空間（エアタイム）という一本道を奪い合い、大渋滞を起こしているのだ。

今回は、Wi-FiにおけるQoSの根幹である WMM（Wi-Fi Multimedia） と、その背後にある 4つの優先制御クラス、そして現場のインフラエンジニアが知るべきEDCAの深淵について、泥臭い実務の知見を交えて徹底的に解説しよう。

—

1. なぜWi-Fiに「交通整理（QoS）」が必要なのか？

有線LAN（イーサネット）の世界であれば、スイッチのバッファや帯域の暴力で、多少のトラフィック過多は力技でねじ伏せることができた。しかし、無線LAN（Wi-Fi）の媒体である「電波」は共有媒体（Shared Medium）だ。誰かが喋っているときは、他の人は電波法や衝突回避のアルゴリズム（CSMA/CA）の都合上、基本的には黙って待たなければならない。

ここで考えてみてほしい。
深夜にダウンロードする数GBのLinux ISOイメージ（Background）と、今まさにリアルタイムで行われているWeb会議の音声（Voice）が、同じ優先順位でエアタイムを奪い合ったらどうなるか？

結果は目に見えている。パケットロスに敏感な音声データが、巨大なファイルのせいで後回しにされ、会議は使い物にならなくなる。だからこそ、無線区間におけるトラフィックの「格付け」が必要なのだ。これがWi-FiにおけるQoSの正体である。

—

2. WMM（Wi-Fi Multimedia）と4つの優先制御クラス

IEEE 802.11e規格をベースに、Wi-Fi Allianceが実用的なサブセットとして策定したのが WMM だ。現代のWi-Fi（Wi-Fi 4から最新のWi-Fi 7まで）において、WMMを有効にしないルーターやクライアントはほぼ存在しないと言っていい。

WMMでは、トラフィックを以下の4つのアクセスカテゴリ（AC: Access Category）に分類し、それぞれ異なる優先順位で電波の送信権（TxOP）を競わせる。

+-------------------------------------------------------------+
| AC_VO (Voice)      : 最優先 (IP電話、VoIP、リアルタイム音声)  |
+-------------------------------------------------------------+
| AC_VI (Video)      : 高優先 (ストリーミング、Web会議の映像) |
+-------------------------------------------------------------+
| AC_BE (Best Effort): 標準   (一般的なWeb閲覧、メール、API通信)|
+-------------------------------------------------------------+
| AC_BK (Background) : 低優先 (ファイルダウンロード、バックアップ)|
+-------------------------------------------------------------+

それぞれのクラスがどのように扱われるのか、現場のエンジニア視点で紐解いていこう。

① AC_VO (Voice) – 音声

  • ターゲット: VoIP、SIP、Teams/Zoomの音声ストリーム
  • 特徴: 遅延とジッター（揺らぎ）に対して最もシビア。パケットが数ミリ秒遅れるだけで人間の耳にはプチプチとしたノイズとして聞こえるため、絶対に死守すべき最優先クラス。

② AC_VI (Video) – 映像

  • ターゲット: 動画配信（Netflix, YouTube）、Web会議の映像
  • 特徴: 音声ほど超低遅延である必要はないが、スループットと連続性が求められる。もし帯域が足りなくなればフレームレートが落ちるか画質が低下する。

③ AC_BE (Best Effort) – ベストエフォート

  • ターゲット: 一般的なWebブラウジング（HTTP/HTTPS）、API通信、SNS
  • 特徴: 特別なマーキングがされていないトラフィックは、すべてここに落ちる。ネットワーク全体の「平穏」を保つためのベースライン。

④ AC_BK (Background) – バックグラウンド

  • ターゲット: OSのアップデート、クラウドストレージの同期、ファイルバックアップ
  • 特徴: 「急がないが、確実に送りたい」データ。他のクラスの邪魔をしないように、エアタイムが空いている隙を狙ってこっそり送信される。

—

3. なぜ優遇されるのか？EDCAパラメータの裏側

「優先クラスがあるのは分かったが、ルーターはどうやってそれを実現しているのか？」
ここで登場するのが、CSMA/CAを拡張した EDCA（Enhanced Distributed Channel Access） だ。

有線のように中央集権的なルーターがすべてを制御するのではなく、無線端末（STA）とAPがそれぞれ自律分散的に競合（Contention）しながらアクセス権を奪い合うのだが、クラスごとに「待ち時間」や「送信権の長さ」を変えることで、事実上の優先制御を行っている。

EDCAを構成する主なパラメータは以下の3つだ。

1. AIFSN (Arbitration Interframe Space Number)

  • パケットを送信する前に「電波が空いているか確認してから待つ時間（IFS）」の基本単位。
  • 値が小さいほど、早く送信を試みることができる。 （AC_VOは短く、AC_BKは長い）

2. CWmin / CWmax (Contention Window)

  • 混雑時にランダムバックオフ（衝突を避けるために待つ乱数の範囲）を決める窓の大きさ。
  • 窓が小さいほど、再試行の抽選に早く当たりやすい。 （AC_VOは狭く、AC_BKは広い）

3. TXOP (Transmission Opportunity)

  • 一度送信権を獲得した端末が、連続してデータを送り続けられる最大時間。
  • 値が大きいほど、一度に大量のデータを流せる。 （AC_VIやAC_VOは大きく確保される）

これらパラメータの典型的なデフォルト値のバランスをイメージすると以下のようになる。

[AC_VO] 待ち時間(短) ──> 即座に送信！ (TXOP: 長め)
[AC_VI] 待ち時間(中) ──> まあまあ早く送信 (TXOP: 長め)
[AC_BE] 待ち時間(長) ──> 普通に待つ
[AC_BK] 待ち時間(最長) ──> ひたすら空気を読んで待つ

現場のトラブルシューティングにおいて、もし「特定のIoTデバイス（Background扱いされがちなセンサー類）の反応が異常に遅い」といった問題に直面した場合、アクセスポイント側のEDCAパラメータがメーカー独自の省電力ロジック等で極端に絞られていないかを疑うのが定石だ。

—

4. アプリケーション開発者・インフラ運用者が知るべき実装と設定

「ふむ、QoSの理屈はわかった。では、Webアプリやインフラの現場で、我々はこの仕組みをどう意識し、活用すべきなのか？」

実は、Wi-FiのWMMは、上位レイヤーである IPパケットのDSCP（Differentiated Services Code Point） や 802.1P（VLAN TagのPCP） とマッピング（関連付け）されて動作している。

例えば、インフラエンジニアが企業向けWi-Fi（RADIUS認証やエンタープライズモード）を構築する際、あるいは開発者がリアルタイム性の高いWebRTCアプリケーションを設計する際、パケットに適切なマーキングを施すことが、無線区間でのWMM優遇を引き出す鍵となる。

Pythonによる簡易的なDSCPマーキングの概念（ソケットプログラミングの例）

Pythonの socket ライブラリを使い、IPヘッダーのTOS（Type of Service）フィールド、すなわちDSCP値を操作して音声系トラフィックとしてのマーキングを行うコードのイメージを見てみよう。

import socket

def create_voice_socket():
    # IPv4, UDPソケットを作成 (VoIP等のリアルタイム通信を想定)
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    
    # DSCPの値を設定するためのTOSバイトを計算
    # 例: EF (Expedited Forwarding) ＝ DSCP 46 (バイナリ: 101110)
    # IPヘッダーのTOSフィールドは上位6bitがDSCP、下位2bitがECN
    # 46を左に2ビットシフトしてトス値とする (46 << 2 = 184)
    dscp_ef = 46
    tos_value = dscp_ef << 2
    
    # ソケットオプション（IP_TOS）を設定
    # これにより、OSのネットワークスタック経由でルーターへ送られるパケットにDSCPが付与される
    s.setsockopt(socket.IPPROTO_IP, socket.IP_TOS, tos_value)
    
    print(f"[Info] ソケットにDSCP値 (EF: {dscp_ef}, TOS: {tos_value}) を適用しました。")
    return s

if __name__ == "__main__":
    # 実務でのデバッグや疎通確認の第一歩として
    sock = create_voice_socket()
    # 宛先アドレスとポートを指定して送信処理へ...

Linux環境（iproute2 / tcコマンド）でのQoSマッピング設定例

自宅のルーターの手前にあるLinuxルーターや、エッジデバイス側でトラフィックを制御する場合、tc (Traffic Control) コマンドを使ってパケットを分類し、Wi-Fiインタフェースへ送り出す際の優先度を制御することがある。

以下は、特定のポート（例: 5060番のSIP/VoIP通信）宛てのパケットを最優先クラス（1:10）に振り分ける設定スクリプトの例だ。

#!/bin/bash

# 対象の無線LANインタフェース名（環境に合わせて変更）
WIFI_DEV="wlan0"

# 1. 既存のqdisc（キューイング規 disciplina）をクリア
tc qdisc del dev $WIFI_DEV root 2>/dev/null

# 2. ルートにPRIO qdiscを設定（デフォルトで3つのバンドを作成）
tc qdisc add dev $WIFI_DEV root handle 1: prio

# 3. ポート5060（SIP）宛てのパケットを、最も優先度の高いバンド（1:1）にフィルターで振り分ける
tc filter add dev $WIFI_DEV protocol ip parent 1:0 prio 1 u32 match ip dport 5060 0xffff flowid 1:1

echo "[Success] Wi-Fiインタフェース $WIFI_DEV に対する優先制御フィルターを適用しました。"

こうしたOSレベル・ルーターレベルでのマーキングと、Wi-Fi空間でのWMM（EDCA）がガッチリ噛み合うことで、混雑した無線環境であっても「音声だけは絶対に途切れない」という堅牢な通信インフラが完成する。

—

5. シニアからの実務Tips：現場でハマりがちな罠

最後に、現場でよくある「Wi-Fi QoSにまつわるトラブル」をいくつか共有しておこう。

1. 「WMM無効化」の罠
古い一部の省電力ルーターや、互換性を最優先した初期設定において、WMMが無効（Disable）になっているケースがある。これをやると、最新のWi-Fi 6やWi-Fi 7であっても、すべての通信が強制的に「最古の速度（レガシーレート）」に引きずり下ろされ、スループットが激減する。Wi-Fiの高速規格（802.11n以降）の仕様上、WMMの有効化は必須である。
2. アップリンク（端末からAP）とダウンリンク（APから端末）の非対称性
AP側の設定でQoSをいじっても、手元のスマホやPC（クライアント側）が適切なDSCPをつけて送信してくれなければ、上り方向（アップリンク）のトラフィックは正しくEDCAのキューに振り分けられない。アプリ層でのマーキングや、OS側のQoSポリシー（WindowsのQoSポリシーやmacOSのQoSマーク）も意識する必要がある。
3. 過剰な優先制御は毒になる
「すべてのトラフィックを重要だ」として、なんでもかんでも AC_VO や AC_VI にブチ込むエンジニアがたまにいる。しかし、これは本末転倒だ。優先クラスの枠がパンクすれば、結局は中で大渋滞が起きる。本当に遅延を嫌う最小限のトラフィックだけを絞り込むのが、正しいインフラ設計の美学である。

—

まとめ

Wi-FiにおけるQoS（WMM）は、目に見えない電波の海を航海するパケットたちにとっての「救命艇の優先ルール」のようなものだ。

Voice、Video、Best Effort、Backgroundという4つのクラス、そしてそれを裏で支えるEDCAのパラメータの挙動を正しく理解していれば、単なる「電波が弱い・強い」という次元を超えた、ロジカルで精緻なネットワーク設計・トラブルシューティングが可能になる。

次にあなたのWeb会議の音声が途切れたり、APIの応答が怪しくなったりしたときは、ぜひ背後でうごめくパケットたちの交通整理の様子に思いを馳せてみてほしい。ネットワークの構造がクリアに見えてくるはずだ。

スポンサーリンク

コメント

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