無線ネットワークとモバイル通信
無線ネットワークは現代のインターネットアクセスの中核です。スマートフォン、ノートPC、IoTデバイスなど、ほとんどのインターネット接続が無線を通じて行われています。
この記事では、無線リンク固有の特性、WiFi（802.11）プロトコルの構造と動作、セルラーネットワークの発展、そして移動性管理メカニズムを見ていきます。
1. 無線ネットワークの構成要素
無線ネットワークの構成
========================
[有線インターネット]
|
[基地局/AP] ----無線---- [無線ホスト]
| リンク [無線ホスト]
| [無線ホスト]
[有線ネットワーク]
構成要素：
1. 無線ホスト：スマートフォン、ノートPC、タブレット
2. 基地局（Base Station）：AP、セルタワー
3. 無線リンク：ホストと基地局間の通信チャネル
4. ネットワークインフラ：基地局を有線ネットワークに接続
1.1 無線ネットワークの分類
無線ネットワークの分類
========================
| インフラあり | インフラなし
-----------------+--------------------+------------------
単一ホップ | WiFi、4G LTE | Bluetooth
|（AP/基地局経由） |（デバイス間直接）
-----------------+--------------------+------------------
マルチホップ | 無線メッシュ | MANET、VANET
|（リレー使用） |（アドホックネットワーク）
2. 無線リンクの特性
2.1 有線との違い
無線リンクは有線リンクと根本的に異なる特性を持ちます。
無線リンクの主要特性
======================
1. 経路損失（Path Loss）
- 信号強度が距離に応じて急激に減少
- 自由空間：距離の二乗に反比例
- 屋内：壁、家具などによる追加減衰
2. マルチパスフェージング（Multipath Fading）
- 信号が複数の経路で反射・回折して到達
- 複数の信号が合成されて強化または相殺
3. 干渉（Interference）
- 同じ周波数を使用する他のデバイスとの干渉
- 電子レンジ、Bluetoothなど（2.4GHz帯域）
4. SNR（Signal-to-Noise Ratio）
- 信号対雑音比：高いほどエラーが減少
- SNRが高い場合：高い変調率、高い伝送率
- SNRが低い場合：低い変調率、低い伝送率
2.2 隠れ端末問題
隠れ端末問題（Hidden Terminal Problem）
=========================================
障害物
[A] .....|..... [B] ---------- [C]
| | | |
| Aの範囲 | Bの範囲 |
|<----->| |<----------->|
| |
AはCを検知不可
CはAを検知不可
問題：
AがBに送信中
Cがチャネルを検知：「空いている！」（Aの信号を検知できず）
CもBに送信開始 --> Bで衝突発生！
これが無線でCSMA/CDを使用できない理由
3. WiFi（IEEE 802.11）
3.1 802.11アーキテクチャ
802.11ネットワーク構造
========================
BSS（Basic Service Set）：
[AP（Access Point）]
/ | \
[H1] [H2] [H3]
無線ホスト
ESS（Extended Service Set）：
[AP1] --- 有線 --- [AP2] --- 有線 --- [AP3]
/ \ / \ / \
[H1][H2] [H3][H4] [H5][H6]
主要構成：
- BSS：1つのAPに接続された無線ホストのグループ
- AP：有線ネットワークと無線ホストを接続するブリッジ
- SSID：ネットワーク識別名（例：「MyWiFi」）
- チャネル：1~11（2.4GHz）または36~165（5GHz）
3.2 802.11接続過程
WiFi接続過程
==============
1. AP発見
- 受動スキャン：APが定期的にビーコンフレームを送信
- 能動スキャン：ホストがプローブ要求を送信、APが応答
2. 認証および接続
ホスト AP
|--- 認証要求（Authentication）-->|
|<-- 認証応答 --------------------|
|--- 接続要求（Association）----->|
|<-- 接続応答 --------------------|
3. DHCPでIPアドレスを取得
4. データ転送開始
3.3 802.11 MACプロトコル：CSMA/CA
無線環境では衝突検出（CD）が困難なため、衝突回避（CA）を使用します。
CSMA/CAの動作
===============
1. キャリアセンス（Carrier Sense）
- DIFS（Distributed Inter-Frame Space）間チャネルが空いていれば送信
2. チャネルが使用中の場合：
- ランダムバックオフタイマー開始
- チャネルが空いている時のみタイマーカウントダウン
- タイマー = 0になったら送信
3. ACK確認
- 受信側がSIFS（Short Inter-Frame Space）後にACKを送信
- ACK未受信時に再送（バックオフ値を増加）
タイムライン：
送信者：[DIFS待機][データ送信]....[タイムアウト]
受信者： [SIFS][ACK]
CSMA/CD vs CSMA/CA：
CD：衝突検知後即座に中断（イーサネット）
CA：衝突回避 + ACK確認（WiFi）
3.4 RTS/CTSメカニズム
隠れ端末問題を解決するためのオプションメカニズムです。
RTS/CTSの動作
===============
送信者A AP 受信範囲のノード
| | |
|-- RTS ----------->| |
| （送信要求） | |
| |---- CTS ------------->|
|<-- CTS -----------| （チャネル予約通知） |
| | |
|== データ ========>| |
| | |（送信自制）
|<-- ACK -----------| |
| | |
RTS：Request to Send（送信要求）
CTS：Clear to Send（送信許可）
CTSを受信したすべてのノードは指定された時間中送信を自制
--> 隠れ端末問題を解決
3.5 802.11フレーム形式
802.11フレーム構造
====================
+-------+------+------+------+------+-----+------+------+-----+
|Frame |Dur- |Addr |Addr |Addr |Seq |Addr |Data | CRC |
|Control|ation | 1 | 2 | 3 |Ctrl | 4 | | |
| 2B | 2B | 6B | 6B | 6B | 2B | 6B |0-2312| 4B |
+-------+------+------+------+------+-----+------+------+-----+
4つのMACアドレスフィールド：
アドレス1：受信無線インタフェースのMAC
アドレス2：送信無線インタフェースのMAC
アドレス3：APに接続されたルータインタフェースのMAC
アドレス4：アドホックモードでのみ使用
なぜ3つのアドレスが必要か：
H1 --> AP --> ルータ（R1）
アドレス1：APのMAC（無線受信者）
アドレス2：H1のMAC（無線送信者）
アドレス3：R1のMAC（最終宛先方向）
4. 802.11標準の発展
WiFi標準の発展
================
標準 | 発売 | 周波数 | 最大速度 | 特徴
----------+-------+-----------+------------+------------------
802.11b | 1999 | 2.4 GHz | 11 Mbps | 初期普及
802.11a | 1999 | 5 GHz | 54 Mbps | OFDM
802.11g | 2003 | 2.4 GHz | 54 Mbps | bと互換
802.11n | 2009 | 2.4/5 GHz | 600 Mbps | MIMO
（WiFi 4）| | | |
802.11ac | 2013 | 5 GHz | 6.9 Gbps | MU-MIMO
（WiFi 5）| | | |
802.11ax | 2020 | 2.4/5/6 | 9.6 Gbps | OFDMA
（WiFi 6）| | GHz | |
5. セルラーネットワーク
5.1 セルラー構造
セルラーネットワークの基本構造
================================
[セル1] [セル2] [セル3]
/ \ / \ / \
/ \ / \ / \
/ BTS \ / BTS \ / BTS \
（基地局） （基地局） （基地局）
| | |
+----------+----------+
|
[BSC/RNC]
（基地局制御装置）
|
[MSC/MME]
（移動交換局）
|
[コアネットワーク] --- [インターネット]
セル（Cell）：1つの基地局がカバーするエリア
周波数再利用：隣接しないセルで同じ周波数を使用
5.2 世代別の発展
セルラーネットワークの世代別発展
==================================
世代 | 技術 | 速度 | 特徴
-------+----------+----------------+------------------
1G | AMPS | 2.4 Kbps | アナログ音声
2G | GSM | 14.4 Kbps | デジタル音声
2.5G | GPRS | 56-114 Kbps | パケットデータ
2.75G | EDGE | 384 Kbps | 拡張データ
3G | UMTS | 2 Mbps | モバイルインターネット
3.5G | HSPA | 14 Mbps | 高速パケット
4G | LTE | 100 Mbps~1Gbps | All-IPネットワーク
4.5G | LTE-A | 3 Gbps | キャリアアグリゲーション
5G | NR | 20 Gbps | 超低遅延、IoT
5.3 4G LTEアーキテクチャ
4G LTEネットワーク構造
========================
[UE] --無線-- [eNodeB] --- [S-GW] --- [P-GW] --- [インターネット]
| | |
| [MME] [PCRF]
| （移動性管理） （ポリシー/課金）
|
[HSS]
（加入者DB）
UE： User Equipment（ユーザー端末）
eNodeB： 基地局（evolved Node B）
S-GW： Serving Gateway（データ経路管理）
P-GW： Packet Gateway（インターネット接続）
MME： Mobility Management Entity（移動性管理）
HSS： Home Subscriber Server（加入者情報）
主要特徴：
- すべてのトラフィックがIPパケットで送信（All-IP）
- 音声もVoLTE（Voice over LTE）で処理
- フラットなアーキテクチャ（階層削減で遅延最小化）
6. 移動性管理
6.1 移動性のスペクトラム
移動性レベル
=============
移動なし 高い移動性
|-------|--------|--------|--------|---------|
固定 低移動 中移動 高移動 超高速移動
デスクトップ WiFi 歩行者 車両 高速鉄道
ローミング ハンドオフ ハンドオフ
6.2 ハンドオフ（Handoff/Handover）
ハンドオフ過程
===============
移動端末が1つの基地局から別の基地局へ移動：
[旧BS] .... [移動端末] .... [新BS]
| |
| 信号弱化 信号強化 |
| |
|<--- ハンドオフ決定 --------->|
| |
|---- トラフィック経路切替 --->|
| |
ハンドオフの種類：
1. ハードハンドオフ：旧接続を切断して新接続（GSM）
2. ソフトハンドオフ：両方に同時接続を維持（CDMA）
ハンドオフ基準：
- 信号強度（RSSI）
- 信号品質（SINR）
- 負荷分散
6.3 間接ルーティングと直接ルーティング
移動性サポート：間接ルーティング
==================================
ホームネットワーク 訪問先ネットワーク
[ホームエージェント] [外部エージェント]
| |
|<---- 移動端末登録 ----------|
| |
通信相手 --> ホームエージェント --> 外部エージェント --> 移動端末
（トンネリング） （転送）
短所：三角ルーティング（Triangle Routing）
通信相手が訪問先ネットワークのすぐ隣にいても
ホームネットワークを経由しなければならない
直接ルーティング：
通信相手がホームエージェントで現在位置を確認
その後直接外部エージェントに送信（三角ルーティング回避）
7. 無線セキュリティ
WiFiセキュリティプロトコルの発展
==================================
プロトコル | 発売 | 暗号化 | セキュリティレベル
-----------+-------+------------+-----------
WEP | 1999 | RC4 (40bit)| 非常に脆弱（使用禁止）
WPA | 2003 | TKIP | 過渡期的
WPA2 | 2004 | AES-CCMP | 良好
WPA3 | 2018 | SAE + AES | 強力
WPA2の動作（4-wayハンドシェイク）：
1. APがランダム値を送信
2. クライアントがランダム値 + MICを送信
3. APがグループキー + MICを送信
4. クライアントが確認を送信
--> 両側がセッションキーを安全に共有
CSMA/CAの送信1回を最後まで追いかける
3.3節ではCSMA/CAを3行で要約しました。フレーム1つが実際に空中へ出るまでにどのような待機と判断を経るのかを最後まで追ってみると、WiFiの実効スループットが規格表の最大速度に遠く及ばない理由がはっきりします。
CSMA/CA 送信1回 (DCF)
========================
[送信するフレームが発生]
|
v
(1) キャリアセンス
チャネルは物理的に空いているか?
|
+-- 空いている --> DIFS の間ずっと空いていれば直ちに送信
|
+-- 使用中 -----> (2)
v
(2) バックオフに入る
競合ウィンドウ CW の中からスロット数を一様乱数で1つ引く
backoff = 0 以上 CW 以下の整数 (単位: スロット)
|
v
(3) スロットのカウントダウン
媒体が空いているスロットごとに backoff を1減らす
媒体が再び使用中になったらカウンタをその場で停止 (freeze)
媒体が DIFS の間また空いたら残った値から再開 (resume)
|
v
(4) backoff が 0 --> データフレームを送信
|
v
(5) 受信側がフレームを正常に受信
SIFS だけ待ってから ACK を送信
|
v
(6) ACK 到着 --> 成功。CW を最小値にリセット
ACK なし --> 失敗とみなす。CW を広げて (2) に戻る
ここで押さえるべき点が3つあります。
1つめは停止と再開です。バックオフカウンタは媒体が空いているスロットでのみ減ります。カウントダウンの途中で他のステーションが送信を始めるとカウンタはその場で止まり、媒体が再び空いたときには乱数を引き直すのではなく残っていた値から続けて数えます。たとえば7スロットを引いて3まで数えたところで媒体が混み始めたなら、次の機会は7ではなく3から始まります。この規則がなければ、長く待ったステーションが毎回最初から競争をやり直すことになり、後から来たステーションに押され続ける可能性があります。残り値を保存するからこそ、すでに長く待った側が次のラウンドで先に出られる確率が高くなります。
2つめは、なぜ802.11にはACKが必要でイーサネットには不要なのかです。イーサネットは送信中に自分が出した信号と媒体上の信号を比較して衝突を検出できます。これがCD、すなわち衝突検出です。無線ではこの比較が成立しません。送信中の無線インターフェースのアンテナには自分の送信信号が圧倒的に大きく入るため、遠くのステーションの信号がその上に重なって届いても区別する手段がありません。しかも衝突は送信側のアンテナではなく受信側のアンテナで発生します。送信者が自分の場所でどれだけよく聞いても、問題が起きている地点は別の場所です。そのため802.11は検出をあきらめて回避へ方針を変え、送信が実際に成功したかどうかは受信側が返すACKだけで判断します。ACKが来ないという事実そのものが唯一の失敗シグナルです。
3つめは、ACKがなぜSIFSの後に出るのかです。SIFSはDIFSより短く、この長さの差だけで優先順位が生まれます。新しいフレームを送ろうとするステーションは最低でもDIFSを待たなければならないのに対し、ACKを送る受信側はより短いSIFSを待つだけでよいので、常に先に媒体をつかみます。結果として、すでに進行中のデータとACKの交換が、新たに始まろうとする交換より必ず先に立ちます。具体的なマイクロ秒の値はPHYと帯域によって変わるため、使用中の規格文書で確認してください。ここで重要なのは絶対値ではなく、SIFSがDIFSより短いという順序関係そのものです。
競合ウィンドウと二進指数バックオフ
競合ウィンドウCWは、バックオフのスロット数を引く範囲です。送信が失敗するたびにこの範囲が広がります。
二進指数バックオフ (概念)
============================
試行1 : CW = CWmin --> 狭い範囲から引く (早く出られる)
試行2 : CW を約2倍に拡大
試行3 : CW をさらに約2倍に拡大
...
試行n : CW = CWmax で拡大を停止
リセット条件:
- そのフレームが ACK を受けて成功した --> CW = CWmin
- 再送上限を超えてフレームを破棄した --> CW = CWmin
CWmin / CWmax の実際のスロット数は PHY とアクセスカテゴリ (QoS) ごとに
異なるため、使用中の規格・ドライバの文書で確認すること
範囲が広がると2つのステーションが同じスロット番号を引く確率が下がるので、競合が激しくなるほど衝突確率は自動的に下がります。その代わり平均待ち時間も一緒に伸びます。つまりCWはステーションが単独で推定する「今このチャネルはどれくらい混んでいるか」の短期指標であり、1回の成功でその推定値はリセットされます。混雑したカフェで体感速度が階段状に落ちる理由は、たいていこれです。ステーションが増えれば衝突が増え、衝突が増えればCWが大きくなり、CWが大きくなれば実データではなく待ち時間に使われる時間が増えます。
隠れ端末をA-B-Cで解いてみる
2.2節の図を時間順に書き直してみます。ステーションA、受信側B（通常はAP）、ステーションCが一直線上にあり、AとCはそれぞれBの電波範囲内にありますが、互いの電波範囲の外にあります。
隠れ端末: 失敗する順序
=========================
t0 A: キャリアセンス --> 空き。DIFS 経過。送信開始
C: キャリアセンス --> 空き (A の信号は C に届かない)
t1 A: ===== データフレーム送信中 =====> B
C: 依然として空きに見える。DIFS 経過。送信開始
t2 C: ===== データフレーム送信中 =====> B
B: A の信号と C の信号が同時に到着 --> 衝突
t3 B: どちらも復号できない --> ACK を送らない
A: ACK タイムアウト --> 失敗。CW を広げて再送
C: ACK タイムアウト --> 失敗。CW を広げて再送
要点:
A も C も自分の視点ではルールを完璧に守っている。
物理キャリアセンスは「自分が聞いている場所」の状態しか教えず、
衝突が起きる場所は「受信者がいる場所」である。
物理キャリアセンスの限界がここにそのまま現れます。AもCもルールを守ったのに衝突し、双方が再送に入ってCWを広げます。負荷が高いとこの失敗が繰り返され、チャネル時間のかなりの部分が成功しない送信で浪費されます。
RTS/CTSはこの問題を「媒体が空いているかを耳で聞く問題」から「誰が媒体を予約したかを知る問題」へ変えます。
RTS/CTS と NAV
=================
A B (AP) C
| | |
|--- RTS (duration) ---->| |
| | |
| |--- CTS (duration) ---->| C は A を聞けないが
|<--- CTS (duration) ----| | B は聞ける
| | |
| | | C: NAV を設定
|=== データ ============>| | (duration の間は送信禁止)
| | |
|<--- ACK ---------------| |
| | | C: NAV 満了 --> 競合再開
RTS と CTS フレームの duration フィールドは
「この交換が終わるまでの残り時間」を格納する。
この値を聞いたすべてのステーションは、その時間だけカウントダウンする
NAV (Network Allocation Vector) を設定する。
NAVが仮想キャリアセンスと呼ばれるのはこのためです。ステーションはNAVがゼロでない間、実際には何も聞こえていなくても媒体は使用中とみなします。CはAのデータフレームを物理的にはまったく聞き取れませんが、Bが送ったCTSのduration値のおかげで、今は自分の出番ではないと知ることができます。物理センスと仮想センスのどちらか一方でも使用中なら、媒体は使用中です。
正直なトレードオフもあります。RTS/CTSはデータフレーム1つごとに短い制御フレーム2つと、その間のSIFS間隔を余分に消費します。このコストはデータ長と無関係な固定コストなので、フレームが短いと本体より大きくなります。VoIPやゲームのパケットのように小さなフレームが大半を占めるトラフィックでRTS/CTSを無条件に有効化すると、かえってスループットが落ちます。そのため多くの実装はRTS閾値（RTS threshold）を持ち、フレーム長がその値を超えるときだけRTS/CTSを使います。デフォルト値は使用中のドライバ／APの文書で確認してください。
接続が成立するまで: スキャン、認証、結合、鍵交換
3.2節の4段階を実際のフレーム順に展開すると次のようになります。
スキャンからデータ転送まで
=============================
[1] スキャン (Scanning) -- どの AP があるかを探す
受動スキャン: チャネルを1つずつ移りながらビーコンを待つ
AP -->(ビーコン)--> すべてのステーション (周期的送信)
能動スキャン: チャネルごとにプローブ要求を投げて応答を受ける
STA --(プローブ要求)--> AP
STA <--(プローブ応答)-- AP
[2] 認証 (Authentication) -- 802.11 層の形式的な手続き
STA --(認証要求)--> AP
STA <--(認証応答)-- AP
WPA2 環境ではたいてい Open System でそのまま通過する。
実際の本人確認は [4] で行われる。
[3] 結合 (Association) -- この AP の BSS に所属する
STA --(結合要求: 対応レート, 能力情報)--> AP
STA <--(結合応答: ステータスコード, AID)-- AP
AID を受け取った時点から AP はこのステーション用のバッファを管理する。
[4] 鍵交換 -- WPA2 は 4-way ハンドシェイク、WPA3 は SAE
この段階が終わって初めて暗号化されたデータフレームが流れる。
[5] DHCP で IP アドレスを取得 --> データ転送開始
ビーコンは単なる「ここにいます」という合図ではありません。ビーコンフレームの本文には、SSID、APが対応する送信レートの一覧、能力情報、ビーコン送信周期、動作チャネル、セキュリティ方式（RSN情報）、そして省電力モードのステーション向けのトラフィック表示情報が入ります。ステーションはビーコンを1つ受け取るだけで、このAPに接続できるのか、接続するならどのレートでどのセキュリティ方式になるのかを、結合を試みる前に判断できます。
受動スキャンが遅い理由もここから出てきます。受動スキャンはステーションが何も送信せず待つだけなので、あるチャネルにAPがあるかを知るには、そのチャネルでビーコンが1回出るまで留まらなければなりません。ビーコンは周期的にしか出ないためチャネルあたり最低でもビーコン周期だけ待つ必要があり、これをスキャン対象チャネル数だけ繰り返すと、全体のスキャン時間はチャネル数に比例して伸びます。能動スキャンはプローブ要求を先に投げて即座に来る応答を受け取るので、チャネルあたりの滞在時間がはるかに短くなります。その代わりステーションは自分の存在と探しているSSIDを空中にまき散らすことになり、一部の規制帯域では先に送信すること自体が制限されるため、そうしたチャネルでは受動スキャンが強制されます。バッテリーの観点でも両者は異なります。受動スキャンは長く起きている必要があり、能動スキャンは短い代わりに送信を伴います。
認証と結合を分けて理解しておくことも役に立ちます。802.11の認証段階は歴史的な遺物に近く、WPA2環境では実質的な検証をせずに通過します。実際にパスワードを知っているかを確認しセッション鍵を作る作業は、結合が終わった後の4-wayハンドシェイクで行われます。だからこそ「パスワードが違うのになぜ結合までは成功したのか」というログを目にすることになります。結合は成功しており、失敗したのは鍵交換です。
実際にスループットを削っているもの
規格表の最大速度と実測値の差は、その大半が次の3つから生じます。
レート適応とエアタイム不公平
無線リンクはSNRに応じて変調・符号化方式（MCS）を絶えず変えます。信号が良ければ高いMCSで密に載せて送り、遠ざかったり干渉が増えたりすると再送が増えるため、ドライバのレート制御アルゴリズムが自動的に低いMCSへ下げます。Linuxのmac80211ではminstrel系のアルゴリズムがこの役割を担います。低いMCSに下がるということは、同じバイト数を送るのにより長い時間を使うということです。
問題は、CSMA/CAが公平に分配するのは帯域幅ではなく送信機会だという点です。
エアタイム不公平 (airtime unfairness)
========================================
同じ大きさのフレームをそれぞれ1回ずつ送るとする。
近いクライアント (高 MCS) : [==] 短い占有
遠いクライアント (低 MCS) : [==================] 長い占有
DCF は送信の「回数」をおおむね公平に分ける。
したがって遅いクライアント1台がチャネル時間の大半を持っていく。
結果: 速いクライアントのスループットも一緒に崩れる。
遅い1台が全体を遅い側へ引きずり下ろす。
これが「隅にあるノートPC1台のせいでオフィス全体のWiFiが遅くなる」という現象の正体です。帯域幅の問題ではなくチャネル時間の配分の問題なので、APをより速い機種に替えても解決しません。カバレッジを狭くしてAPを増やし、すべてのクライアントが高いMCSを使えるようにするか、エアタイム公平性機能に対応した機器を使うほうが正しい対処です。
同一チャネル干渉と隣接チャネル干渉
この2種類を区別しないと診断になりません。同一チャネル干渉（co-channel interference）は、まったく同じチャネルを使う他のAPとそのクライアントがいる場合です。このとき相手の信号は自分にとって復号可能な802.11信号なのでキャリアセンスが正常に働き、全員が同じチャネル時間を分け合うことになります。スループットは落ちますが動作は正常です。隣接チャネル干渉（adjacent-channel interference）は周波数が部分的に重なる場合です。相手の信号をフレームとして復号できず雑音としてしか受け取らないためキャリアセンスが正しく働かず、結果として互いの送信をただ壊し合います。再送率が急激に上がります。
直感に反しますが、チャネルが足りないときは隣接チャネルへ逃げるより同一チャネルで重なるほうが良い場合が多いのです。
2.4 GHz 帯の 20 MHz チャネル
==============================
チャネル番号: 1 2 3 4 5 6 7 8 9 10 11
|---20MHz---|
|---20MHz---|
|---20MHz---|
^ ^ ^
1 6 11
多くの規制ドメインで 2.4 GHz はチャネル間隔が狭く、
20 MHz 幅では互いに重ならない組み合わせが事実上 1 / 6 / 11 の3つだけになる。
--> AP が4台以上なら必ずチャネルが再利用される。
5 GHz は非重複の 20 MHz チャネルがはるかに多い。
--> チャネル計画の余裕が根本的に違う。
(利用可能なチャネルと DFS 要件は規制ドメインごとに異なるため、
該当国の規定と機器の文書で確認すること)
2.4 GHzでチャネル3やチャネル9のような「空いているように見える」チャネルを選ぶのはよくある誤りです。そのチャネルはチャネル1ともチャネル6とも部分的に重なるため、両方にとって雑音になり、両方から雑音を受けます。
失敗事例と落とし穴
症状: 電波は満タンなのに遅い
もっともよくある申告であり、もっともよく誤診される症状です。アンテナ3本が立っているのはRSSIが高いという意味であって、リンクが健全だという意味ではありません。RSSIは自分が受け取る信号の強さであり、自分の送信が相手に無事届いているかについては何も語りません。
診断の順序
=============
1) まず再送率を見る
tx retries が tx packets に対して数 % を超えるならリンクの問題である。
RSSI がどれだけ良くても再送が多ければチャネルが汚れている。
--> 干渉源、隣接チャネルの重なり、隠れ端末を疑う
2) 実際の MCS / tx bitrate を見る
ネゴシエートされた物理速度がリンクの規格に比べて大きく低ければ、
レート制御アルゴリズムはすでに下がった状態にある。
--> 距離、障害物、アンテナの向き、帯域 (2.4 vs 5 GHz) を確認
3) チャネル占有率を見る
上の2つが正常なのに遅いなら、問題は自分のリンクではなく
チャネルそのものが混んでいる。
--> 同一チャネルの他 AP / クライアント数、エアタイムを確認
4) 最後に RSSI を見る
RSSI は 1-3 の原因を説明するときに使う補助指標であり、
出発点ではない。
Linuxではこれらの値を iw で直接確認できます。以下の例はインターフェース名が wlan0 の場合なので、自分の機器のインターフェース名に置き換えて使ってください。文書上の書式は iw dev <devname> link のように表記されます。
# 現在の接続の概要: SSID、周波数、信号強度、ネゴシエートされた tx bitrate
iw dev wlan0 link
出力例
========
Connected to 02:11:22:33:44:55 (on wlan0)
SSID: office-5g
freq: 5180
RX: 184203311 bytes (152884 packets)
TX: 21944072 bytes (61230 packets)
signal: -47 dBm
tx bitrate: 54.0 MBit/s
読み方:
signal -47 dBm --> RSSI は非常に良い (「アンテナ満タン」)
tx bitrate の行に MCS の表記がまったくない
--> HT/VHT レートではなくレガシーレートまで落ちているという意味である。
健全な 802.11n リンクなら、カーネル文書の例のように
tx bitrate: 300.0 MBit/s MCS 15 40Mhz short GI
という行が出る。MCS 番号とチャネル幅が一緒に表示される。
信号が良いのにレートが低い = 干渉によりレート制御が下がったサイン。
RSSI ではなくこの行を先に見るべき理由がこれである。
# 再送カウンタまで含む詳細統計
iw dev wlan0 station dump
station dump が表示する項目のうち診断に実際に使うのは、tx retries、tx failed、tx bitrate、rx bitrate、signal avg です。tx retries が tx packets に対して目に見えて大きければ、信号強度とは無関係にこのリンクはすでに問題を抱えています。出力項目の正確な名前と構成はドライバとカーネルのバージョンによって変わるため、使用中のバージョンの文書で確認してください。
症状: 特定の時間帯だけ切れる
この場合の診断順序は異なります。まずその時間帯に人が増えるのか（エアタイム競合）、次に電子レンジやコードレス電話のような非802.11の干渉源が動作するのか、最後に5 GHz帯であればレーダー検出によるチャネル移動が起きているのかを見ます。前の2つは再送率の上昇として現れ、最後の1つは短い完全断とチャネル番号の変更として現れるので、ログで区別できます。
落とし穴: RTS/CTSを無条件に有効にする
隠れ端末問題を学ぶと、RTS閾値を最小まで下げてすべてのフレームにRTS/CTSを適用したくなります。隠れ端末が実際には存在しない環境では、これは純粋な損失です。フレームごとに制御フレーム2つとSIFS間隔が加わるため、小さなフレームが多いトラフィックではスループットが目に見えて落ちます。RTS/CTSは「再送率が高く、その原因は干渉ではなく互いに聞こえないステーションである」という診断が立った後に有効化する道具です。
無線を使わないほうがよい場合
無線は利便性で有線を圧倒しますが、次の3つの場合は有線が正解です。
1つめは、遅延が決定的で予測可能でなければならないワークロードです。CSMA/CAは本質的に確率的です。バックオフのスロットを乱数で引き、媒体が混んでいればカウンタが止まり、失敗すればCWが大きくなります。平均遅延が低くても最悪遅延の上限を保証できません。産業用制御、リアルタイム音声の同期、高頻度取引のように遅延の裾が重要な場所では、無線の平均値がどれだけ良くても使えません。
2つめは、ステーション密度が高く、制約が帯域幅ではなくチャネル時間である場合です。講堂やカンファレンス会場のように1つの空間に数百台が集まる環境では、APの規格速度をいくら上げても役に立ちません。すべてのステーションが1つのチャネル時間を分け合い、ステーション数が増えるほど衝突とバックオフに使われる時間の比率が大きくなるからです。こうした場所で必要なのは、より速いAPではなく、より細かいセル設計とチャネル再利用計画、そして可能なら有線のバックアップです。
3つめは、RF環境を統制できない場合です。無線の性能は隣のAP、窓の外の道路、壁の中の配管のように自分では手を出せない要素に左右されます。サーバラックの間、共用オフィスビル、賃借スペースのように周辺スペクトラムを管理する権限がない環境で無線リンクにサービス可用性を賭けると、原因を特定することも直すこともできない障害を抱え込むことになります。サーバ間通信、バックアップ、ストレージのトラフィックのように切れてはいけない経路は有線に置くのが正しい判断です。
逆に無線が確実に正解になる場合も明確です。移動性が要件そのものである場合、配線コストが性能損失を上回る場合、そして遅延の裾がユーザー体験に影響しない一般的なWebやストリーミングのトラフィックです。
8. まとめ
| 概念 | 核心内容 |
|---|---|
| 経路損失 | 信号強度が距離に応じて急激に減少 |
| 隠れ端末 | 相手の送信を検知できず衝突が発生 |
| CSMA/CA | 衝突回避 + ACK確認方式 |
| RTS/CTS | チャネル予約で隠れ端末問題を解決 |
| 802.11フレーム | 4つのMACアドレスフィールドを含む |
| セルラー | セル単位の周波数再利用、世代別の発展 |
| 4G LTE | All-IPネットワーク、フラットなアーキテクチャ |
| ハンドオフ | 基地局間の移動時に接続を切り替え |
次の記事では、マルチメディアネットワーキングとストリーミング技術を見ていきます。
参考資料
- James F. Kurose, Keith W. Ross, "Computer Networking: A Top-Down Approach", 6th Edition, Chapter 6
- IEEE 802.11 - Wireless LAN Standard
- 3GPP TS 36.300 - LTE Architecture
802.11はRFCではなくIEEE標準です。標準そのものはIEEEで、Linux側のツールはカーネルの文書で確認するのが適切です。
- IEEE 802.11 Working Group（WLAN標準のワーキンググループ。IEEE 802標準の無料ダウンロード案内を含む） — https://www.ieee802.org/11/ （2026-08-16 確認）
- IEEE Std 802.11-2020, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications"（現在はIEEE Std 802.11-2024に置き換え） — https://standards.ieee.org/ieee/802.11/7028/ （2026-08-16 確認）
- IEEE P802.11 プロジェクトページ（最新改訂の進行状況） — https://standards.ieee.org/ieee/802.11/11852/ （2026-08-16 確認）
- Linux Wireless, iw の使用例（
iw dev wlan0 link、iw dev wlan1 station dump、iw dev wlan0 scan、iw list） — https://wireless.docs.kernel.org/en/latest/en/users/documentation/iw.html （2026-08-16 確認） - Linux Wireless, mac80211 の文書（Rate Control / minstrel） — https://wireless.docs.kernel.org/en/latest/en/developers/documentation/mac80211.html （2026-08-16 確認）