ネットワークエンジニアの皆さん、日々のインフラ運用やAPI設計、本当にお疲れ様です。深夜のトラブルシューティングでパケットキャプチャを開き、TCP Retransmissionの嵐に頭を抱えた経験は、誰しも一度や二度ではないはずです。
私たちはこれまで、いかに「1本の太いパイプ（シングルリンク）」を通すかに腐心してきました。Wi-Fi 6（802.11ax）のOFDMAや1024-QAMの導入により、単一帯域でのスループットは極限まで高められましたが、それでも避けて通れなかったのが「干渉」と「遅延の揺らぎ（ジッタ）」という物理的障壁です。
電子レンジの稼働や近隣の電波干渉によって、ある瞬間だけパケットロスが跳ね上がり、Web APIのレスポンスタイムが数秒にハネ上がる――。この「見えないストレス」を根本から覆すゲームチェンジャーこそが、IEEE 802.11be、すなわち Wi-Fi 7 で実装された MLO（Multi-Link Operation） です。
今回は、このMLOがパケットレベルでどのように動き、私たちのアプリケーション層（Web APIやリアルタイム通信）にどのような恩恵をもたらすのか、現場のシニアエンジニアの視点から徹底的に解説します。
—
1. MLO（Multi-Link Operation）とは何か？ リンクアグリゲーションの無線版
これまでのWi-Fi（Wi-Fi 6 / 6Eまで）は、クライアント端末とアクセスポイント（AP）の間で、2.4GHz、5GHz、あるいは6GHzのいずれか「1つの周波数帯域」を選んで通信していました。マルチバンドルータであっても、接続時はどれか1つのリンクが排他的に使われます。
これに対し、Wi-Fi 7のMLOは、キャリアアグリゲーションの概念を無線LANに持ち込みました。端末とAPが複数のバンド（例: 5GHzと6GHz）を同時に束ねて通信を行います。
MLOの3つの動作モード
標準規格（IEEE 802.11be）において、MLOは大別して以下のモードを持ちます。
1. STR（Simultaneous Transmit and Receive / 同時送受信）
- 最も理想的なモード。例えば、リンクA（5GHz）で送信しつつ、同時にリンクB（6GHz）で受信することが物理的に可能です。ハードウェア的なアイソレーション（干渉防止）が必要となります。
2. NSTR（Non-Simultaneous Transmit and Receive / 非同時送受信）
- 同一チップ内で送受信のタイミングを時分割するモード。STRほどのフルパフォーマンスは出ませんが、ハードウェアコストを抑えつつマルチリンクの恩恵を受けられます。
3. EMLSR（Enhanced Multi-Link Single Radio）
- 1つの無線機（ラジオ）を基本としながら、複数のリンクを同時に監視し、必要に応じて動的にリンクを切り替える省電力かつ高効率なモード。近年のモバイル端末で主流になりつつあります。
—
2. パケットが駆け巡る仕組み：MLOの通信フローと冗長性
インフラエンジニアとして気になるのは、「実際にパケットがどうルーティングされ、ロスト時にどうリカバリされるのか」という点でしょう。
OSI参照モデルのデータリンク層（MAC層）において、MLOは複数の物理リンクを仮想的な1つのMAC層（Multi-Link Logical Entity）に統合します。これにより、上位層（IP / TCP / UDP）からは、あたかも「極めて太く、絶対に切れない1本の回線」に見えるようになります。
[Webブラウザ / アプリケーション層]
│
▼
[TCP / UDP トランスポート層]
│
▼
[IP ネットワーク層]
│
▼ (マルチリンク仮想化レイヤー)
┌──────────┴──────────┐
▼ ▼
[Link 1: 5GHz帯] [Link 2: 6GHz帯] <-- 物理的パスの多重化
│ │
└──────────┬──────────┘
▼
[Wi-Fi 7 AP]パケット多重化とパケット複製（Redundant Transmission）の挙動
MLOの真骨頂は、単なる帯域の合算（スループット向上）だけではありません。ミッションクリティカルなトラフィック向けに、「同一パケットを複数リンクで同時に送出する（パケット複製モード）」が規定されています。
- 通常モード（Load Balancing）: 大容量の動画ストリーミングやAPIのレスポンス受信において、トラフィックを5GHzと6GHzに分散してスループットを最大化します。
- 高信頼モード（Redundant Mode）: 遠隔医療、産業用IoT、あるいはレイテンシが厳しく問われるリアルタイムWeb APIのKeep-Aliveなどにおいて、同じフレームを両方のリンクへ同時に送出します。片方のリンクで激しい干渉やパケットロスが発生しても、もう片方のリンクのパケットが正常に到達していれば、再送制御（ARQ）のオーバーヘッドをゼロに抑えられます。
—
3. 実務で知るべきパラメーターと設定・デバッグの視点
ネットワーク機器の設定ファイル（例えば、企業のキャンパス無線やOpenWrtベースのカスタムAP）や、クライアント側のデバッグにおいて、MLO関連のパラメーターはどのように現れるでしょうか。
無線パケットアナライザ（Wireshark等）でキャプチャした際、BeaconフレームやAssociation Request/Responseの中に、「Multi-Link Element」というIE（Information Element）が出現します。
パラメーターのポイント
- Link ID: 各リンクを識別するインデックス（例: 5GHz帯が
0、6GHz帯が1）。 - STA MAC Address: リンクごとに割り当てられるMLD（Multi-Link Device）MACアドレスと、各リンク固有のMACアドレスのマッピング。
- BSSID: リンクごとに異なるAPのBSSID。
以下は、Linux環境（wpa_supplicant や iw コマンド）における、MLOの状態確認やデバッグのイメージです。
# 現在接続しているWi-FiインターフェースのMLOリンク状態を確認する
$ iw dev wlan0 link
# 出力例（概念的なイメージ）
Connected to 00:11:22:33:44:55 (on wlan0)
SSID: Enterprise-Wi-Fi-7
freq: 5180 (Link ID: 0)
freq: 6115 (Link ID: 1) <-- 5GHzと6GHzの複数リンクがアクティブ
MLD MAC Address: aa:bb:cc:dd:ee:ff
Active Links: Link 0 (5GHz), Link 1 (6GHz)
Operating Mode: STR (Simultaneous Transmit and Receive)現場のトラブルシューティングにおいて、「片方のリンクだけリンクアップして、もう片方がネゴシエーションに失敗する」という現象に遭遇することがあります。その原因の多くは、AP側のファームウェアの不具合、あるいは近隣のDFS（Dynamic Frequency Selection）チャンネルとのバッティングによるレーダー検知に伴う一時的なチャネル無効化です。
—
4. アプリケーション開発者への影響：Web API設計とレイテンシの捉え方
インフラ基盤がWi-Fi 7 / MLOに進化することで、WebアプリケーションやAPIを設計するエンジニアの「前提条件」はどう変わるでしょうか。
これまで、モバイル環境からのAPIリクエストにおいて、無線区間の突発的なパケットロスによるTCPの輻輳制御（Slow StartやTCP Retransmission Timeout）が原因で、レスポンスタイムが数百ミリ秒〜数秒跳ね上がることがありました。
PythonによるAPIレイテンシ測定スクリプト例
MLO環境下でのAPI通信の安定性を評価するため、以下のような簡単なPythonスクリプトで定期的にレイテンシの揺らぎ（ジッタ）を計測し、ログに残すアプローチが有効です。
import time
import requests
from requests.exceptions import RequestException
# 監視対象のAPIエンドポイント
API_ENDPOINT = "https://api.example.com/v1/healthcheck"
TIMEOUT_SEC = 3.0
def monitor_api_latency(iterations=100, interval=1.0):
print(f"Starting MLO network latency test against {API_ENDPOINT}...")
for i in range(iterations):
start_time = time.time()
try:
# 実際のAPIリクエスト送信
response = requests.get(API_ENDPOINT, timeout=TIMEOUT_SEC)
elapsed = (time.time() - start_time) * 1000.0 # ミリ秒に変換
if response.status_code == 200:
print(f"[{i+1}] Status: OK | Latency: {elapsed:.2f} ms")
else:
print(f"[{i+1}] Status: HTTP Error {response.status_code} | Latency: {elapsed:.2f} ms")
except RequestException as e:
# 無線区間の瞬間的な切断やパケットロスによるタイムアウトを検知
print(f"[{i+1}] ERROR: Request failed due to {e}")
time.sleep(interval)
if __name__ == "__main__":
monitor_api_latency()MLOが適切に機能している環境下では、仮に5GHz帯の電波状況が悪化してパケットロスが発生しかけても、6GHz帯側のリンクが即座に補完するため、上記スクリプトにおける Latency のスパイク（跳ね上がり）や Timeout の発生率が劇的に低下します。
—
5. まとめ：これからのネットワークとエンジニアの心得
Wi-Fi 7のMLOは、単に「通信速度が速くなる（理論値が上がる）」というマーケティング上の数字の遊びではありません。「無線通信の信頼性を、有線LANのレベルに近づけるための極めて泥臭いエンジニアリングの結晶」です。
複数の周波数帯を束ね、パケットレベルで冗長化し、ジッタを極限まで押し下げるこの技術は、今後のリアルタイムWebアプリケーション、IoTデバイスの管理、そしてオフィスやスマートファクトリーのインフラ設計において、なくてはならない標準技術になっていきます。
「無線だからパケットロスや遅延があって当たり前」というこれまでの常識を捨て、インフラとアプリケーションの両面から、この新しい「マルチリンクの時代」をしっかりと乗りこなしていきましょう。
皆さんのネットワーク環境が、常に安定したパケットの奔流に満たされていますように。
コメント