【テクニカル・上級編】無線エラー原因とトラブルシューティング：Out-of-SyncおよびRadio Link Failure（RLF） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

パケットの消失と再同期の深淵：RLF（Radio Link Failure）とRRC再確立の内部挙動を解き明かす

無線通信の現場において、最も静かで、しかし最も致命的な瞬間のひとつが「Radio Link Failure（RLF）」の発生だ。

高層ビルの峡谷を抜ける風のように、あるいはフェージングの谷間を通過する瞬間に、私たちのデバイスと基地局（gNB / eNB）をつなぐ見えない電波のパイプラインは、突如としてその整合性を失う。

ネットワークエンジニアやインフラアーキテクトであれば、iperfのグラフが急降下する瞬間や、TCPコネクションが突然の FIN またはサイレントドロップに直面する光景に心当たりがあるはずだ。しかし、そのトランスポート層の悲劇の裏側では、エアインターフェース（Uuインターフェース）のレイヤー2およびレイヤー3において、壮絶なサバイバル劇が繰り広げられている。

今回は、レイヤー1の同期判定からタイマー T310 の満了、そしてRRC（Radio Resource Control）再確立（Re-establishment）に至るまでのパケットレベルの内部挙動を、Linuxカーネルやプロトコルスタックの視点を交えながら徹底的に解き明かしていく。

—

1. 無線リンクの生死を分ける：In-Sync と Out-of-Sync のメカニズム

モバイル通信（LTE / 5G NR）において、デバイス（UE）は常に物理層で下りリンク（DL）の品質を監視している。この監視の主役となるのが、基準信号（LTEならCRS、5G NRならSSB / CSI-RS）を用いた無線リンク監視（RLM: Radio Link Monitoring）だ。

物理層は、受信した基準信号の誤り率（BLER: Block Error Rate）を継続的に測定し、上位層（RRC層）に対して以下の2つのプリミティブを通知する。

Out-of-Sync (OOS): 下りリンクの無線品質が特定の閾値（仮にPDCCHの仮説BLERが10%相当）を下回ったと判定された状態。
In-Sync (IS): 品質の回復により、閾値（BLERが2%相当など）を上回ったと判定された状態。

この判定は単発のイベントではなく、物理層から数ミリ秒単位の周期でRRC層へとレポートされる。RRC層はこのレポートを受け取り、内部のカウンターやタイマーを駆動させる。

ここでエンジニアが注意すべきなのは、このレイヤー1の判定が、上層のTCPやアプリケーション層の挙動とは完全に非同期で、かつミリ秒単位の極めてタイトな世界で処理されているという点だ。

—

2. タイマー T310 のカウントダウンとRLFの検知

Out-of-Syncの通知が連続すると、RRC層は「無線リンクが危険な状態にある」と判断し、防衛機制を発動する。ここで登場するのが、3GPP仕様で定義されたお馴染みのタイマー群だ。

1. カウンター N310 の発動:
RRC層が物理層から連続して N310 回のOut-of-Sync通知を受け取ると、タイマー T310 が起動する。
2. タイマー T310 の稼働と救済措置:
T310 がカウントダウンしている間に、もし無線品質が回復し、物理層から連続して N311 回のIn-Sync通知を受け取れば、危機は去ったとみなされ T310 は停止する。
3. タイマー T310 の満了（RLFの確定）:
しかし、電波環境の悪化が続き、T310 がタイムアウトを迎えると、ついに Radio Link Failure (RLF) が正式に検知される。

この瞬間、UEのRRC層の状態は RRC_CONNECTED から、接続回復を試みる特殊なサスペンド状態へと移行する。同時に、タイマー T311 が起動し、接続先となり得る適切なセル（キャンディデート・セル）の探索が始まる。

—

3. RRC再確立（RRC Connection Re-establishment）のパケット挙動

RLFを検知したUEは、ただちに接続を切断するわけではない。データプレーンのパケットは一旦ブロックされるが、制御プレーンでは「RRC再確立プロセス」という最後の望みをつなぐハンドシェイクが実行される。

このプロセスのパケットレベルの挙動を追ってみよう。

ステップ1: プライマリセルまたはネイバーセルの選定とランダムアクセス（RACH）

UEは T311 が稼働している間に、測定レポートや物理セルID（PCI）を元に最も品質の良いセルを特定し、そのセルに対して非競合あるいは競合ベースのランダムアクセス手続き（Msg 1 / Msg 2）を開始する。

ステップ2: RRCConnectionReestablishmentRequest の送信

ランダムアクセスが成功すると、UEは新しいセル（または元のセル）のgNBに対して、RRCメッセージ RRCConnectionReestablishmentRequest を送信する。このメッセージの中には、以下の極めて重要な情報が含まれている。

ue-Identity: 以前のセルで割り当てられたC-RNTI（Cell Radio Network Temporary Identifier）と短縮S-TMSI、あるいはPCI
establishmentCause: 再確立の理由（reestablishment）

このメッセージを受け取ったgNB側は、過去のコンテキスト（UE Context）を内部のデータベースやモビリティ管理エンティティ（AMF / MME）との間で保持・照合し、該当するUEであると認証できれば、再確立の許可を下ろす。

ステップ3: RRCConnectionReestablishment の応答

gNB側でコンテキストの復旧が成功した場合、RRCConnectionReestablishment メッセージが暗号化（SRB1での完全性保護と暗号化）されて下りリンクで送信される。

このパケットがUEに到達した瞬間、無線リンクは奇跡的に復活を遂げ、データプレーンのベアラ（DRB）が再開される。

—

4. インフラ・チューニングの現場：パフォーマンスとRTT削減の極意

ここまでの挙動を踏まえ、高密度な無線環境やモビリティの高いユースケース（車載通信やAGVなど）において、どのようにRLFの発生頻度を抑え、パフォーマンスの低下を防ぐべきか。現場のインフラエンジニアが調整可能な主要パラメーターとチューニングのアプローチを見ていこう。

1. N310 / T310 / N311 の最適化

デフォルトのパラメータは汎用的な環境を想定して保守的に設定されているため、高速移動体や遮蔽物の多い工場内などでは、誤検知による頻繁なRLFや、逆に検知遅延によるパケットロッドを引き起こす。

// 例：RRCレイヤーにおける無線リンク監視タイマー・カウンターのカスタム設定概念（JSON表現）
{
  "radioLinkMonitoringConfig": {
    "n310": "n20",      // Out-of-Syncの連続検知回数を多めに設定し、一瞬のフェージングによる誤検知を抑制
    "t310": "ms2000",   // タイマーT310の満了時間を2秒に設定
    "n311": "n1"        // In-Syncの必要回数を設定し、迅速な回復判定を促す
  }
}

2. トランスポート層（TCP）およびTLSへの影響とバッファチューニング

RLFが発生し、RRC再確立に成功するまでの数テンミリ秒から数百ミリ秒の間、パケットはエアインターフェース上で完全にストップする。この間、TCPのトランスポート層では無音状態となり、輻輳ウィンドウ（cwnd）の縮小やRTO（Retransmission Timeout）の暴発リスクが高まる。

この遅延スパイクに対応するため、Linuxカーネル側ではBBR（Bottleneck Bandwidth and Round-trip propagation time）輻輳制御アルゴリズムの採用や、適切なTCPバッファチューニングが極めて有効となる。

# LinuxカーネルにおけるTCP輻輳制御アルゴリズムの確認とBBRへの変更
# RLF起因の一時的な帯域急減・遅延スパイクに対し、BBRは損失ベースではなく帯域とRTTをベースに動作するため有利
sudo sysctl net.core.default_qdisc=fq
sudo sysctl net.ipv4.tcp_congestion_control=bbr

# 現在の設定を反映させるための確認コマンド
sysctl net.ipv4.tcp_congestion_control

さらに、TLS 1.3環境下においては、RLFからの復帰直後に発生するセッション再ネゴシエーションやハンドシェイクの遅延を最小限に抑えるため、TCPのキープアライブやTLSの早期データ（0-RTT）機能を慎重に設計・検証する必要がある。セキュリティを維持しつつ、無線リンクの一時的な断絶に対する耐性を高めるこのバランス調整こそが、インフラアーキテクトの腕の見せ所だ。

—

5. 結びにかえて：見えないエラーを観測し、手なづける

Out-of-Syncから始まり、タイマー T310 のカウントダウンを経てRLF、そしてRRC再確立へ至る一連のプロセスは、いわば無線ネットワークの「セーフティネット」である。

教科書や仕様書の文字面を追うだけでは見えてこない、パケットがエアインターフェースの境界線上で消え、そして再び結ばれるその瞬間——。この内部挙動を解像度高く理解しているかどうかが、大規模なスマートファクトリーやミッションクリティカルなIoTネットワークの設計品質を決定づける。

電波は目に見えないが、プロトコルの挙動は嘘をつかない。ログとパケットキャプチャの奥底にあるシグナルを読み解き、極限のパフォーマンスを引き出すネットワークを構築し続けよう。