【実務・中級編】 NGAPにおけるInitial UE MessageとPDU Session Resource Setup Requestのパケットフロー – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5Gの「見えない絆」を紐解く：NGAPで紐解くInitial UE MessageとPDU Session確立の深淵

ネットワークエンジニアの皆さん、こんにちは。現場で日々パケットと格闘していると、「スマホが電波を掴んだ」という当たり前の現象が、いかに緻密な握手（ハンドシェイク）の積み重ねで成り立っているかに驚かされますよね。

今日は、5G（SA：Standalone）環境におけるコアネットワークと無線アクセスネットワークの境界線、すなわち NGAP（Next Generation Application Protocol）のシグナリングフローに深く切り込んでいきます。特に、「端末が通信を始める瞬間の儀式」である Initial UE Message から PDU Session Resource Setup に至るまでの動きを、実務的な視点で解説します。

—

1. 接続の狼煙：Initial UE Messageの役割

端末（UE）がRRC接続を確立し、無線資源を確保した直後、gNB（基地局）からAMF（Access and Mobility Management Function）に向けて放たれるのが Initial UE Message です。

これは単なる挨拶ではありません。UEの識別子（SUCI/SUPI）や、UEの能力情報、そして「どのネットワークスライスを使いたいか」といった、後の通信品質を左右する極めて重要な情報が詰め込まれています。

パケットの裏側で起きていること

現場のトラブルシューティングでよく遭遇するのが、このメッセージに含まれる NAS-PDU の解釈エラーです。AMF側がこの NAS-PDU を正しく復号できないと、認証プロセスさえ始まらず、端末は「圏外」のまま取り残されます。

Wiresharkでこのパケットをキャプチャする際、注目すべきは UE Radio Capability です。端末が「私はミリ波も使えるし、Sub6のキャリアアグリゲーションもいけるぜ」と自己申告する内容が、このメッセージに依存しているからです。

—

2. データの通り道を作る：PDU Session Resource Setup Request

認証・認可が終わり、いよいよ通信の準備が整うと、AMFはgNBに対して「このUEのためにトンネルを掘れ」と命令を下します。これが PDU Session Resource Setup Request です。

ここでは、UPF（User Plane Function）との接続に必要な GTP-U（GPRS Tunneling Protocol User Plane）のトンネルエンドポイント情報が渡されます。

実務で意識すべきパラメーター

インフラ運用において最も注意すべきは QoS Flow Profile です。ここで 5QI（5G QoS Identifier）が適切に設定されていないと、遅延が許されない通信（URLLC）であってもベストエフォート以下の品質になりかねません。

—

3. 実践：シミュレーターでフローを再現する

実務では、実機だけでなく UeSim や CoreSim といったツールでシミュレーションを行うことも多いでしょう。以下は、設定ファイルの一部をPython風の構造体で表現したイメージです。

# PDU Session Resource Setup Request の構成要素例
pdu_session_setup_request = {
    "PDU Session ID": 5,
    "NAS-PDU": "0x0078...", # 認証済みのNASメッセージ
    "S-NSSAI": {
        "SST": 1,          # Slice Service Type (1=eMBB)
        "SD": "000001"     # Slice Differentiator
    },
    "QosFlowSetupRequestList": [
        {
            "QFI": 9,      # QoS Flow Identifier
            "QoSLevel": {
                "5QI": 9,  # 9はデフォルトのベストエフォート
                "ARP": {"PriorityLevel": 15}
            }
        }
    ],
    "UL-NGU-UP-TNL": {
        "TransportLayerAddress": "192.168.10.20", # UPFのIPアドレス
        "GTP-TEID": "0x00000001"                  # トンネルエンドポイント識別子
    }
}

エンジニアの皆さんならお分かりの通り、この TransportLayerAddress や GTP-TEID に誤りがあると、制御プレーン（NGAP）は成功しても、ユーザープレーンが全く疎通しないという「制御は通るのに通信ができない」という悪夢のようなトラブルを引き起こします。

—

4. デバッグの現場から：curlでAPIと重ね合わせる

モバイル通信のバックエンドでは、このNGAPフローと連動して、Web APIが認証状態を更新することがあります。例えば、バックエンドのステータス管理に curl を使う場合、以下のようなワークフローが一般的です。

# 端末のセッション状態を確認する（イメージ）
curl -X GET "https://api.core-network.internal/v1/sessions/ue-123456" \
     -H "Authorization: Bearer <TOKEN>" \
     -H "Content-Type: application/json" \
     -d '{
           "query_target": "pdu_resource_status",
           "check_tunnel": true
         }'

もし、NGAP側で PDU Session Resource Setup Response が届いているのに、このAPIでステータスが INACTIVE となっていれば、それは「無線区間はOKだが、コア内の論理ゲートが閉じている」という明確な切り分けが可能です。

—

最後に：ネットワークを「感じる」ために

教科書的な仕様書はあくまで地図であり、実際の現場は生きた生き物です。NGAP のパケット一つ一つには、端末が電波を掴もうともがいた痕跡や、コアネットワークがそれを柔軟に受け入れるための苦労が刻まれています。

トラブルシューティングでパケットを眺める際は、単なる「値の羅列」として見るのではなく、「端末が今、どんな通信品質を要求して、ネットワークがどう応えようとしているのか」という物語を読み解いてみてください。

技術は日々進化しますが、パケットの挙動を深く理解する姿勢は、どんな時代でも一流のエンジニアを支える唯一の武器になります。次回の運用や開発の現場で、この記事が少しでも皆さんのトラブル解決のヒントになれば幸いです。

それでは、また次回の記事でお会いしましょう。現場からは以上です！