【実務・中級編】 IEEE 802.11規格における制御フレームの構造（RTS、CTS、ACK、BlockACK） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは。現場のシニアネットワークエンジニアとして、日々数々の無線トラブルやパケットロスと格闘している私です。

Webアプリケーションの設計やクラウドインフラの構築に携わるエンジニアの多くは、HTTPのステータスコードやTCPの3ウェイハンドシェイク、TLSのネゴシエーションといった「レイヤー4以上」の挙動には非常に敏感です。APIのレスポンスが遅ければ curl でレイテンシを測り、パケットキャプチャでTLSのハンドシェイク不良を追いかける。それは素晴らしいアプローチです。

しかし、そのパケットがあなたのPCやスマートフォンからWi-Fiルーターへ飛び出す「エアインターフェース（レイヤー1/2）」で、今、何が起きているか想像したことはあるでしょうか？

「Wi-Fiが何となく遅い」「大人数が接続するオフィスやイベント会場でパケットが詰まる」――その原因の多くは、上位層のボトルネックではなく、無線空間特有の物理的制約、そしてそれを泥臭く解決するために飛び交う「制御フレーム（Control Frames）」の悲鳴にあります。

今回は、IEEE 802.11規格の根幹を支える制御フレーム（RTS、CTS、ACK、BlockACK）のバイナリレベルの挙動と、それらが無線空間の秩序をどう守っているのかを、実務的な視点を交えて徹底解説します。教科書を斜め読みしただけでは見えてこない、パケットの生々しい実態を一緒に覗いてみましょう。

—

1. なぜ無線空間には「制御フレーム」が必要なのか？

有線LAN（イーサネット）の世界では、全二重（Full-Duplex）通信が当たり前になり、スイッチングハブが衝突（コリジョン）を綺麗に裁いてくれます。しかし、Wi-Fiをはじめとする無線通信の本質は「共有エアウェーブ（共有媒体）」です。電波という目に見えない共通の空気の震えを、周囲の無数のデバイスと奪い合っています。

ここで大きな壁となるのが、無線特有の物理的制約です。

隠れ端末問題（Hidden Terminal Problem）の悪夢

例えば、親機（AP）を中心に、左側に端末A、右側に端末Bが配置されているとします。端末Aと端末Bの距離が遠く、お互いの電波が届いていない場合、AとBは「自分以外の端末が電波を出しているか」をキャリアセンス（CSMA/CA）で検知できません。

結果として、AとBが同時にAPに向けてデータフレームを送信すると、APの真上で電波が激突し、両方のデータが破損（コリジョン）します。これが隠れ端末問題です。APから見れば「なぜかパケットロスが多発する謎の現象」として観測されます。

この物理的な衝突を防ぎ、確実なデータ伝送路を確保するために生み出されたのが、RTS/CTSハンドシェイクです。

—

2. RTS / CTS / ACK / BlockACK のバイナリ構造とシーケンス

IEEE 802.11のフレームは、大別して「データフレーム」「管理フレーム」「制御フレーム」の3つに分かれます。このうち制御フレームにはペイロード（データ本体）が存在せず、MACヘッダーとFCS（フレームチェックシーケンス）のみで構成される非常に軽量なフレームです。

実際の通信フローと、それぞれのフレームが持つ役割を順に見ていきましょう。

① RTS (Request to Send) と CTS (Clear to Send)

隠れ端末問題を解決するため、大容量データを送信する前に周囲の端末へ「これからこのチャネルを占有するから、しばらく送信を待ってくれ」と宣言する仕組みです。

1. 送信端末 → AP: RTS フレームを送信。

  • フレーム制御（Frame Control）フィールドのタイプは「Control (01)」、サブタイプは「RTS (1011)」となります。
  • この中には「これからデータを送信するのに必要な時間（Duration）」がミリ秒単位で書き込まれており、このRTSを受信した周囲の端末は、NAV（Network Allocation Vector）と呼ばれるタイマーをセットし、その間は送信を自主規制（仮想キャリアセンス）します。

2. AP → 送信端末: 周囲の安全を確認し、CTS フレームを返送。

  • サブタイプは「CTS (1100)」です。
  • このCTSを受け取ることで、送信端末は「周囲の端末は沈黙している、今なら安心してデータを送れる」と確信を得ます。

② ACK (Acknowledgment)

有線LANのTCPと同様に、IEEE 802.11のMAC層レベルでも「届いたよ」という確実な返事が必要です。これがACKフレーム（サブタイプ: 1101）です。

データフレームを受信した受信側は、エラーチェック（FCS）を行い、問題がなければ数マイクロ秒のSIFS（Short Interframe Space）という超短時間の間隔を置いて、即座にACKを返します。もしこのACKが一定時間内に返ってこない場合、送信側は「電波の途中でパケットが消えた（または衝突した）」と判断し、再送制御（Retry）を行います。

③ BlockACK (Block Acknowledgement)

現代の高速なWi-Fi（Wi-Fi 6 / 6E / 7など）では、データフレームを1つ送るたびに1つずつACKを返す方式では、オーバーヘッドが大きすぎてスループットが頭打ちになります。

そこで登場するのがBlockACKです。

  • 複数のデータフレーム（アグリゲーションされたA-MPDUなど）をまとめて一気に送信し、受信側は「どのフレームが成功し、どのフレームが欠損したか」をビットマップ形式（Bitmap）でまとめて一括返送します。
  • 例えば、32個のフレームを連続送信し、そのうちの24番目だけがロスしていた場合、BlockACKのビットマップによって「24番目だけピンポイントで再送してくれ」と効率的なリカバリーが可能になります。Wi-Fiの爆発的なスループットは、このBlockACKの高度なハンドリングに支えられています。

—

3. 現場で役立つWi-FiトラブルシューティングとデバッグTips

インフラエンジニアやアプリエンジニアが現場でWi-Fi起因のトラブルに直面した際、どのように原因を切り分ければよいでしょうか。無線パケットを目視することは難しいですが、いくつかの実践的なアプローチがあります。

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

1. RSSI（受信信号強度）とSNR（信号対雑音比）の確認

  • パケットロスや再送多発の根本原因の多くは電波減衰です。端末側のユーティリティや管理画面で、RSSIが -65 dBm より低い状態になっていないか確認します。

2. チャネルコンテンション（混雑）の調査

  • 周囲に同じチャネルを使うAPが多いと、RTS/CTSやバックオフ（ランダム待機時間）が増大し、スループットが劇的に低下します。チャネル幅（20MHz / 40MHz / 80MHz / 160MHz）が過剰に設定されていないかも見直しましょう。

3. Wi-Fiアナライザやパケットキャプチャの活用

  • モニターモード（Promiscuous Mode）をサポートしたWi-Fiアダプターと Wireshark を使い、エア上の無線フレームをキャプチャします。ここで Retry=1 となっているデータフレームの比率や、RTS/CTS が頻発しているかを確認することで、無線空間の荒れ具合を生々しく把握できます。

—

4. 実務でのネットワーク診断に使えるPythonスクリプト例

無線空間の直接的なキャプチャは専用機材が必要ですが、アプリケーション層や上位レイヤーからネットワークの「揺らぎ（ジッターやパケットロス）」を定期監視し、ログに残すスクリプトはインフラ運用の現場で重宝します。

以下に、指定したエンドポイントへの疎通状況とラウンドトリップタイム（RTT）を計測し、異常時に構造化ログを出力するPythonスクリプトのサンプルを掲載します。そのまま現場の監視基盤やCronジョブに組み込んで活用してください。

import time
import subprocess
import platform
import logging
from datetime import datetime

# ログフォーマットの設定（JSONライクな構造化出力のベース）
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)

# 監視対象のデフォルトゲートウェイまたは主要APIサーバー
TARGET_HOST = "192.168.1.1"
PING_COUNT = 3
TIMEOUT_SEC = 2

def measure_network_quality(host: str) -> dict:
    """
    指定されたホストに対してpingを実行し、RTTとパケットロス率を測定する。
    Wi-Fiの不安定さ（遅延スパイクやロス）を検知するための簡易プローブ。
    """
    param = "-n" if platform.system().lower() == "windows" else "-c"
    timeout_param = "-w" if platform.system().lower() == "windows" else "-W"
    
    # pingコマンドの構築
    command = ["ping", param, str(PING_COUNT), timeout_param, str(TIMEOUT_SEC), host]
    
    start_time = time.time()
    try:
        result = subprocess.run(
            command,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True,
            timeout=10
        )
        elapsed = time.time() - start_time
        
        if result.returncode == 0:
            # 成功時の簡易解析（OS依存を避けるためステータスのみ判定）
            return {
                "status": "UP",
                "latency_sec": round(elapsed, 4),
                "error": None
            }
        else:
            return {
                "status": "DEGRADED",
                "latency_sec": None,
                "error": "Packet loss or high latency detected"
            }
            
    except subprocess.TimeoutExpired:
        return {
            "status": "TIMEOUT",
            "latency_sec": None,
            "error": "Ping command timed out entirely"
        }
    except Exception as e:
        return {
            "status": "ERROR",
            "latency_sec": None,
            "error": str(e)
        }

if __name__ == "__main__":
    logging.info(f"Network quality monitoring started for target: {TARGET_HOST}")
    
    # 連続監視のループ（実運用では systemd や cron で管理することを推奨）
    try:
        metrics = measure_network_quality(TARGET_HOST)
        
        if metrics["status"] == "UP":
            logging.info(f"Status: {metrics['status']} | RTT: {metrics['latency_sec']}s")
        else:
            # 警告レベルでログ出力し、アラート連携のトリガーとする
            logging.warning(f"Status: {metrics['status']} | Reason: {metrics['error']}")
            
    except KeyboardInterrupt:
        logging.info("Monitoring stopped by user.")

—

おわりに

私たちが何気なく開いているWebブラウザや、叩いているAPIの裏側では、今回解説したRTS/CTSやACK、BlockACKといった制御フレームが、目に見えない電波の海で毎秒何千・何万回と飛び交い、データの整合性を必死に守っています。

「アプリが重い原因は本当にサーバー側にあるのか？ もしかして足元のWi-Fiレイヤーでパケットが再送の嵐になっていないか？」――こうした多角的な視点を持つことこそが、真に信頼性の高いインフラストラクチャを支えるエンジニアの強みです。

日々のトラブルシューティングや設計の現場で、この記事が少しでもあなたの視座を広げるヒントになれば幸いです。それでは、また次回の技術解説でお会いしましょう。

スポンサーリンク

コメント

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