5Gモビリティの深淵：Xnハンドオーバーがもたらす「切れない」ネットワークの舞台裏
モバイルネットワークの世界では、「切れない」ことは「最強」と同義だ。かつて4G/LTE時代、私たちは X2 インターフェイス越しにパケットをバケツリレーのように繋いできた。だが、5G（NR: New Radio）の時代に入り、コアネットワークのアーキテクチャは NG インターフェイスへと進化し、基地局間（gNB）を繋ぐ Xn インターフェイスは、かつてないほどシームレスな体験を我々に強いている。
今回は、インフラアーキテクトやテックリードの視点から、この「ハンドオーバー」の裏側で何が起きているのか、そしてパケットの寿命を延ばし、レイテンシを極限まで削るためのチューニング手法について深掘りしていく。
—
Xnハンドオーバーの解剖：制御プレーンとユーザープレーンの乖離
ハンドオーバーが発生する際、端末（UE）が移動を検知すると、ソースgNBはターゲットgNBに対して Xn Handover Request を投げる。ここで特筆すべきは、ユーザープレーン（UPF）のパス切り替えの高速化だ。
従来のS1ハンドオーバーでは、コアネットワーク（MME）を経由してパスを切り替えていたため、どうしても物理的な距離とトランスポートのオーバーヘッドがRTT（Round Trip Time）に悪影響を及ぼしていた。しかし、Xn ベースのハンドオーバーでは、ターゲットgNBが直接パケットをバッファリングし、ソースgNBから未送信パケットの転送（Forwarding）を受ける。
パケットロスを防ぐための「転送パケットシーケンス」
ここで重要になるのが PDCP（Packet Data Convergence Protocol）層のシーケンス番号管理だ。ハンドオーバー中にパケットがドロップしないよう、SN（Sequence Number）の引き継ぎが厳密に行われる。
PDCP SNの保護: 転送パケットにはHFN（Hyper Frame Number）を含めた厳密な同期が必要。- ヘッダー圧縮（ROHC）の再同期:
ROHC（Robust Header Compression）の状態をターゲットgNBに引き継ぐ際、コンテキストが破壊されると、その後のパケットがすべてデコード不能になる。これを回避するため、ROHCのコンテキスト情報をXn-U経由で即座に同期させる必要がある。
—
現場で差がつく：TCPバッファとトランスポート層の最適化
5Gのミリ波環境などで、ハンドオーバー直後にスループットがガタ落ちする経験はないだろうか？ これはネットワーク層の問題ではなく、TCP の輻輳制御アルゴリズムが、ハンドオーバーによる瞬断を「輻輳」と誤認してしまうことに起因する。
カーネルパラメータのチューニング例
Linux環境でエンドデバイスの挙動を制御する場合、以下のカーネルパラメータを見直すのが定石だ。ハンドオーバーの瞬間に TCP ウィンドウを急激に絞らせないための設定を検討すべきである。
# BBR (Bottleneck Bandwidth and RTT) を採用する
# 5G環境のようなバーストトラフィックには cubic よりも bbr が圧倒的に有利
sysctl -w net.ipv4.tcp_congestion_control=bbr
# TCPウィンドウサイズを動的に最適化する（ハンドオーバー後の復帰を速める）
# min, default, max の順で指定。5Gの広帯域を活かすなら最大値を大きめに設定
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'
# TCPの急速なウィンドウ縮小を抑制（ハンドオーバーの瞬断対策）
sysctl -w net.ipv4.tcp_slow_start_after_idle=0—
セキュリティの観点：TLSハンドシェイクとモビリティ
ハンドオーバーが発生すると、IPアドレスの変更やルートの切り替えにより、TLS セッションが途切れる可能性がある。特に TLS 1.3 を利用している場合、0-RTT（Zero Round Trip Time）機能の活用が鍵となる。
0-RTT を有効にすることで、クライアントは接続確立の最初のパケットに暗号化されたアプリケーションデータを付与できる。しかし、これは「リプレイアタック」のリスクを伴う。ハンドオーバー時に TLS セッションを再開する際、サーバー側で以下のガードを設けることが、セキュリティのベストプラクティスだ。
# TLS 0-RTTでのリプレイアタックを回避するための疑似ロジック
# サーバー側での実装例
def validate_early_data(request):
# すでに処理済みのチケットIDかを確認する（キャッシュ利用）
if cache.get(request.ticket_id):
return False # リプレイの可能性あり、拒否する
# ハンドオーバー直後のセッション再開であれば、
# 冪等性の高いリクエストのみを許可する
if request.is_idempotent():
return True
return False—
結論：ネットワークは「生き物」である
5Gのインフラ構築において、Xn や NG インターフェイスは単なる接続点ではない。それは、ユーザーが「ネットワークに繋がっていること」を意識させないための、極めて高度な「時間と空間の同期装置」である。
我々インフラ屋に求められるのは、ただ仕様書通りのトポロジーを組むことではない。ハンドオーバーの瞬間に起きるパケットの揺らぎ（Jitter）や、再送制御によるレイテンシのスパイクを、TCPスタックのチューニングやアプリケーション層でのセッション管理でいかに「隠蔽」するかだ。
ネットワークは生き物であり、その挙動は統計的だ。泥臭いパケットキャプチャと、数ミリ秒を削り出すカーネルチューニングの積み重ねこそが、最高のエクスペリエンスを支える唯一の道であると確信している。
次の記事では、ミリ波特有の「ビームフォーミング」と、ハンドオーバー時の「ビーム追従遅延」がどのように QUIC プロトコルに影響を与えるかについて深掘りしていこうと思う。期待していてほしい。
コメント