【実務・中級編】 5G制御プレーンプロトコルNGAP（Next Generation Application Protocol）の基本構造とメッセージ種別 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

「なぜ繋がらない？」を紐解く――5G制御プレーンの心臓部「NGAP」をエンジニア視点で解剖する

ネットワークの現場に立つ皆さん、お疲れ様です。5Gが当たり前になった今、スマホのアンテナピクトが5Gになっても「速度が出ない」「接続が不安定だ」というトラブルに直面したことはありませんか？

多くのエンジニアが「5Gは速い」という結果だけを見ていますが、その裏側でgNB（基地局）とAMF（コアネットワークの制御機能）がどんな会話をしているのか、その「言葉」を知っている人は驚くほど少ない。今回は、5G制御プレーンの要であるNGAP（Next Generation Application Protocol）の深淵を覗いてみましょう。

NGAPとは何か：SCTPという「強固な土管」の上で

NGAPは、3GPP TS 38.413で定義されたプロトコルです。gNBと5Gコア（5GC）を結ぶN2インターフェースで、端末の接続管理やセッション設定を司ります。

ここで重要なのは、NGAPがTCPではなくSCTP（Stream Control Transmission Protocol）の上に乗っているという点です。Webエンジニアには馴染みの薄いSCTPですが、ネットワーク屋にとっては「マルチストリーミング」と「順序保証付きのメッセージング」を提供してくれる、信頼の厚いトランスポート層です。

なぜTCPではダメなのか？それは、制御プレーンでパケットロスやヘッド・オブ・ライン・ブロッキング（先頭のパケットが詰まると後続が全部待たされる現象）が起きると、通信全体が停止してしまうからです。SCTPは複数のストリームを並行して扱うことで、この弱点を克服しています。

現場で役立つメッセージフロー：NG Setupから初期登録まで

実務でデバッグをする際、Wiresharkのキャプチャ画面を開いて最初に見るべきはNG Setup RequestとNG Setup Responseです。ここが通らなければ、基地局は「死んでいる」のと同じです。

主要メッセージの役割

NG Setup Request: 基地局がコアネットワークに「俺はここにいるぞ、設定はこれだ」と挨拶する。
Initial UE Message: 端末がネットワークに入ろうとした時の第一声。NAS（Non-Access Stratum）メッセージをカプセル化して運ぶ。
Initial Context Setup Request: 認証・認可が終わった後、コア側から「この端末に無線リソースを割り当てろ」という指令。

実践：パケット解析とデバッグの勘所

もしあなたがインフラエンジニアとして「端末が接続できない」というアラートを受けたなら、まずSCTPのアソシエーションが確立しているかを確認してください。

以下は、tsharkを使ってNGAPの特定のメッセージを追いかけるためのコマンド例です。

# 5GのN2インターフェース（SCTP 38412番ポート）を監視
# SCTPのチャンクとNGAPのメッセージタイプを絞り込んで抽出する
tshark -i eth0 -f "port 38412" -Y "ngap.procedureCode == 15" -V

※ procedureCode == 15 は NG Setup です。この値を変更すれば、Initial Context Setupなど他の処理も追跡可能です。

コードで理解する：NGAPの構造を模したメッセージ生成

Web API設計に慣れているエンジニアなら、NGAPのメッセージ構造をJSONのような階層構造と捉えると分かりやすいはずです。Pythonの疑似コードで、Initial UE Messageのイメージを記述してみます。

# 5G制御プレーンのメッセージ構築イメージ
ngap_message = {
    "procedureCode": 15, # InitialUEMessage
    "criticality": "reject",
    "value": {
        "ranUeNgapId": 12345, # 基地局内での端末識別子
        "nasPdu": "07410001...", # 暗号化されたNASメッセージ本体
        "userLocationInformation": {
            "nrCellIdentity": "0x1A2B3C" # どのセルから入ってきたか
        }
    }
}

# 実際の通信では、これをASN.1という形式でバイナリエンコードして送出する
# WebエンジニアがJSONを送るのに対し、通信屋はASN.1でゴリゴリに圧縮して送るイメージ

トラブルシューティングの極意：ログを読む技術

最後に、現場で一番多い「あるある」を共有します。それは、Initial Context Setup Requestの中で渡されるPDU Session Resource Setupの失敗です。

QoSプロファイルが不整合: 基地局がサポートしていないQoSフローをコアが要求している。
トランスポート層の不一致: SCTPの心臓部であるエンドポイント設定のIPアドレスが、ファイアウォールでブロックされている。

これらを見極めるには、Wiresharkでngap.causeフィールドを確認するのが鉄則です。causeの中身に「Radio Network Layer」のエラーが出ているのか、「Transport Layer」のエラーなのかを切り分けるだけで、解決へのスピードが段違いになります。

まとめ：ネットワークは「対話」である

5Gのプロトコルスタックは複雑に見えますが、結局のところ「基地局」と「コア」という二つの知的な存在が、SCTPという信頼できる通信路を使って「何をすべきか」を相談し合っているだけです。

「教科書を丸暗記する」のではなく、「このパケットは今、何を求めているのか？」という視点で通信フローを眺めてみてください。パケットの挙動が見えるようになれば、あなたはもう一人前の通信エンジニアです。

次回の現場では、ぜひtsharkを片手に、見えないパケットの行方に想いを馳せてみてください。それでは、また現場で会いましょう！