【実務・中級編】 5G NSA(Non-Standalone)アーキテクチャの制御プレーンとデータプレーンの連携 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5G NSAの「二重底」を読み解く：EN-DCで制御プレーンとデータプレーンが協調する仕組み

現場でネットワークトラブルに立ち向かっているエンジニアの皆さん、お疲れ様です。最近、5G対応のルーターを検証していて「アンテナピクトは立っているのに、なぜかスループットが出ない」「特定のAPIリクエストだけがタイムアウトする」といった現象に頭を抱えたことはありませんか？

多くの国内キャリアが採用している 5G NSA（Non-Standalone） は、既存のLTE（EPC）を「アンカー」として使い、そこに5G NR（New Radio）をアドオンする EN-DC（E-UTRA-NR Dual Connectivity） という仕組みで成り立っています。これが曲者で、制御プレーン（C-Plane）とデータプレーン（U-Plane）が物理的に異なるレイヤーで踊っているような状態なのです。

今回は、この「二重底」の裏側を覗き、API運用やインフラ構築にどう活かすべきか、シニアな視点で解説します。

—

1. なぜNSAでは制御とデータが分離するのか？

NSAアーキテクチャでは、スマホはまずLTEのeNB（マスターノード）とRRC接続を確立します。ここで重要なのは、「制御プレーンの信号はLTE側（アンカー）を通る」というルールです。

一方で、データプレーンはgNB（5G基地局）にオフロードされます。つまり、ネットワーク側から見れば「制御はLTE、データはNR」というマルチホーム的な連携が行われているわけです。この連携がうまくいかないと、セッションのハンドオーバーが失敗し、パケットロスが発生します。

実務で意識すべきシーケンス

1. LTE RRC Connection: まずはLTEで繋がる（これが遅いと5G以前の問題）。
2. Measurement Report: 端末が周囲の5G電波をスキャンし、RSRPやRSRQを基地局に報告。
3. SCG Add: LTE側から「5G使っていいよ」というRRCConnectionReconfigurationが飛ぶ。
4. Data Plane Path Switch: ユーザーデータがNR側へルーティングされる。

—

2. インフラ運用者が監視すべきパラメータ

APIの疎通確認やネットワーク性能のデバッグを行う際、pingやcurlだけで満足してはいけません。特にモバイル網では、以下のパラメータが通信品質を決定づけます。

RSRP (Reference Signal Received Power): 電波の強さ。-100dBmを切ると厳しい。
RSRQ (Reference Signal Received Quality): 電波の質。干渉が多いとここが悪化する。
CQI (Channel Quality Indicator): 端末が「これくらいの変調方式ならいける」と申告する値。APIのスループットに直結します。

Pythonで簡易的なメトリクス取得（イメージ）

ルーターのAPI（REST API等）を叩いて、現在の接続状態をログ出力するPythonコードの例です。

import requests

# ルーターのAPIエンドポイント（例としてダミー）
ROUTER_API = "http://192.168.100.1/api/v1/network/status"

def check_5g_status():
    response = requests.get(ROUTER_API)
    if response.status_code == 200:
        data = response.json()
        # 5G NRセルの接続状態を確認
        if data['nr_status'] == 'connected':
            print(f"5G NR接続中: RSRP={data['rsrp']}dBm, CQI={data['cqi']}")
        else:
            print("警告: LTEのみで動作中。帯域制限の可能性あり")
    else:
        print("APIエラー: ステータス取得失敗")

# 定期的に監視することで、どのタイミングで5Gが切れるかを特定する
check_5g_status()

—

3. 実践：APIリクエストのタイムアウトを防ぐためのTips

Web APIの設計・運用時、モバイル環境特有の「パケットのゆらぎ」を考慮しないと、タイムアウト頻発の地獄を見ます。特にEN-DCでLTEとNRを切り替える際、一瞬の「瞬断」や「ジッタ」が発生します。

運用時のチェックリスト

TCP Keep-Aliveの設定: モバイル網ではNATセッションが短時間で切れることが多いです。keepalive時間を短めに設定してください。
HTTP/2の活用: コネクションの確立コストが高いため、HTTP/2でストリームを多重化し、コネクション再利用を効率化します。
ヘッダーによる接続識別: 可能であれば、X-Network-Typeなどのカスタムヘッダーを付与し、APIサーバー側で「どの経路からのリクエストか」をログ出力できるようにしておくと、障害切り分けが劇的に楽になります。

curlでのデバッグ例

プロキシを通したり、特定のインターフェースから叩く際は以下のように実行します。

# -w オプションでTCPハンドシェイクや接続時間を計測する
# モバイル網特有の「接続の重さ」を数値化して特定する
curl -w "TCP接続時間: %{time_connect}s\nTTFB: %{time_starttransfer}s\n" \
     -H "X-Debug-Mode: 1" \
     -o /dev/null -s "https://api.example.com/v1/data"

—

まとめ：泥臭い検証こそが最強の武器

5G NSAの環境は、技術的には「LTEとNRの綱引き」です。もし皆さんが担当しているサービスで「特定の場所でだけ遅い」という報告が上がったら、まずはその端末がSub6を掴んでいるのか、それともLTEにフォールバックしているのかを確認してください。

ネットワークは生き物です。スペックシートの「最大速度」を鵜呑みにせず、現場でcurlを叩き、メトリクスを収集し、泥臭くパケットを追いかける。その積み重ねだけが、複雑なモバイルネットワークを攻略する唯一の道です。

次回は、5G SA（Standalone）への移行で何が変わるのか、制御プレーンがどのように進化するのかを深掘りしたいと思います。それでは、良いエンジニアリングを！