Beaconの鼓動をチューニングせよ：Wi-Fi 7時代の省電力とレイテンシの相克
Wi-Fi 7（IEEE 802.11be）という新たな時代の幕開けと共に、私たちは「マルチリンク動作（MLO）」による劇的なスループット向上に酔いしれている。しかし、どれほどPHY層が進化しようとも、無線空間の支配者である「Beaconフレーム」の挙動を疎かにするインフラアーキテクトは、真のパフォーマンスを手にすることはできない。
本稿では、Beaconフレームが無線区間の「心臓」としてどのように機能し、特に DTIM（Delivery Traffic Indication Message）の設計が、IoTデバイスのバッテリー寿命と、リアルタイム性を要求される通信のRTT（Round Trip Time）にどのようなトレードオフを強いるのか、深層レベルで紐解いていく。
—
Beaconフレーム：無線空間の「沈黙」を統率するマスター・クロック
Beaconフレームは、単なるAPの存在証明ではない。それは無線空間における同期の基点であり、TSF（Timing Synchronization Function）の基準値そのものだ。
すべての端末は、このBeaconを受け取ることで自らのタイマーをAPと同期させ、スリープ状態とウェイクアップのタイミングを決定する。しかし、この「心拍」の間隔が長すぎれば、省電力には寄与するが、スリープ解除後のパケット送受信における「目覚めの遅延」を誘発する。
DTIM周期が描く省電力とレスポンスの境界線
DTIM周期は、APがバッファリングしていたユニキャスト/ブロードキャストパケットを、省電力（PS-PollまたはU-APSD）モードの端末に向けて「さあ、受け取れ」と解放する合図だ。
- DTIM = 1: すべてのBeaconでバッファをフラッシュする。リアルタイム性は最高だが、モバイル端末は頻繁にRADIOを駆動させる必要があり、バッテリーは容赦なく消費される。
- DTIM = 3 (推奨値): 多くの民生機で採用される。300ms程度の適度な遅延を許容しつつ、バランスを取る設定。
- DTIM > 5: 極限のIoT環境向け。数秒単位のスリープを可能にするが、TCPハンドシェイクの初期応答やTLSハンドシェイクの
Client Helloが最初のDTIMを逃せば、その瞬間にRTTは数百ミリ秒単位で跳ね上がる。
—
現場で刺さるチューニング：Linuxカーネルとバッファの最適化
インフラを設計する際、無線区間だけでなく、その先のホスト・スタックまで考慮しなければ「パケットの渋滞」は解決しない。特に高密度なIoT環境では、TCPの輻輳制御アルゴリズムとバッファサイズが重要だ。
1. TCPウィンドウサイズの適正化
無線区間でパケットロスが発生しやすい環境では、過大な TCP バッファはバッファブロート（Bufferbloat）を引き起こし、レイテンシを悪化させる。
# sysctlでのTCPバッファチューニング例
# ネットワーク帯域が細いIoT環境下での過度なバッファ保持を防ぐ
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
# 輻輳制御アルゴリズムをBBRへ変更（パケットロスに強い）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr2. TLSハンドシェイクの最適化
TLS 1.3が標準となった今、0-RTT（Zero Round Trip Time Resumption）の活用は必須だ。しかし、これにはリプレイ攻撃のリスクが伴う。Beaconの DTIM が長い環境では、最初のハンドシェイクの遅延を 0-RTT で補完することが、UX向上の鍵となる。
# Python/SSLコンテキストでの0-RTT有効化のイメージ
context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
context.set_ciphers('ECDHE-ECDSA-AES128-GCM-SHA256')
# 0-RTTを有効にする場合、再送制御をアプリケーション層で実装する必要がある
context.early_data_enabled = True—
セキュリティの「見えざる穴」を塞ぐ
Beaconフレームは暗号化されない（※WPA3の Management Frame Protection を除く）。そのため、攻撃者が不正な Beacon を射出し、端末を意図的に切断させたり、特定のチャネルへ誘導（Deauth攻撃）することは、依然として無線ハッキングの古典にして王道だ。
- MFP (Management Frame Protection) の強制: WPA3環境では必須だが、WPA2環境でも
802.11wを必ず有効にすること。これを怠ると、Beaconの偽装によってIoTデバイスが無限に再接続を繰り返す「バッテリー枯渇攻撃」の標的となる。 - Beacon Intervalの固定: 動的な間隔変更はハンドシェイクの同期ミスを招く。運用では
100 TU（約102.4ms）に固定し、DTIMを環境に合わせて調整する手法が最も堅牢だ。
結びに代えて：プロトコルが奏でる調和を求めて
Wi-Fi 7の登場により、MLO（Multi-Link Operation）が普及すれば、Beaconの送信間隔やDTIMの重み付けは、リンクごとに動的に制御される時代が来るだろう。しかし、それでもなお、パケットが無線空間を飛び交う際の「一瞬の沈黙」をデザインするのは、エンジニアであるあなた自身だ。
教科書的な設定を鵜呑みにせず、現場のRSSI、パケットロス率、そして接続されるデバイスの特性を見極めよ。Beaconの鼓動を適切にチューニングすることこそが、目に見えないインフラを支配する唯一の道である。
さあ、次はどのパケットを最適化しようか？ネットワークの深淵は、まだ始まったばかりだ。
コメント