5Gの登録シグナリングをキャプチャすると、同じN2接続上で次のような順序をよく見かけます。最初にInitial UE Messageが現れ、続いてUplink NAS TransportとDownlink NAS Transport、その後にInitial Context Setupが続き、UEが実際にデータ接続を確立し始めるとPDU Session Resource Setupが現れます。個々のメッセージを理解すること自体はそれほど難しくありません。難しいのは、なぜこの順序で発生するのか、そしてNGAPが5Gのコントロールプレーン全体で実際に何をしているのかを理解することです。N2はgNBとAMFの間に継続して存在する制御チャネルと考えると分かりやすくなります。まずネットワークノード同士の関係が確立され、次にUEコンテキストが作成され、その後でPDUセッション用のRANリソースが準備されます。UEが移動したりアイドル状態に入ったり、サービスパラメータが変更されたりすると、追加のNGAP手順がトリガーされます。

N2インターフェースは実際に何をするのか？

N2はgNBとAMFの間のコントロールプレーンインターフェースで、NGAP（NG Application Protocol、NGアプリケーションプロトコル）を使用します。機能面では4Gで使われるS1-MMEインターフェースと似た部分がありますが、5Gシステムアーキテクチャ内で動作します。

SCTPはN2のトランスポート層として使用されます。NGAPはSCTP上で動作し、UEと5Gコア間で交換されるNASメッセージはNGAPを介してgNBとAMFの間で運ばれます。したがって、典型的なN2プロトコルスタックは次のように理解できます。IPがgNBとAMF間のネットワーク到達性を提供し、SCTPがN2のトランスポートアソシエーションを提供し、NGAPがN2の制御手順とパラメータを運び、必要に応じて5G NASがNAS-PDUとして転送されます。

NGAP自体はUEの通常のユーザプレーントラフィックを運びません。実際のユーザデータは通常N3ユーザプレーンで転送されます。N2は、リソース確立、UEコンテキスト管理、NASシグナリング転送、モビリティ調整などの制御機能を担当します。機能的には、N2はPDUセッションに関連するNG-RANリソースの確立、維持、解放を支援するとともに、UEコンテキスト管理、モビリティ管理、NASシグナリング転送、ユーザプレーンリソース制御にも関与します。

なぜNGAP手順はUE関連手順と非UE関連手順に分けられるのか？

NGAPを学び始めたとき、数十種類の手順やメッセージ名にいきなり入ると、すぐに暗記作業になってしまいます。より実践的なのは、まずその手順が特定のUEに関係するかどうかを判断することです。

UE関連手順は、特定ユーザのコンテキスト、セッション、またはモビリティ状態を中心に動作します。例として、PDUセッションリソース管理、UEコンテキスト管理、ハンドオーバー、ページング、NAS転送、位置報告、UE無線能力の各手順があります。一方、非UE関連手順は主にgNBとAMFのノードレベルの関係を維持します。代表例はNG Setup、RAN Configuration Update、AMF Configuration Update、NG Reset、AMF Status Indication、Overload Start/Stopです。

この区別はパケットキャプチャのトラブルシューティングで非常に有効です。gNB配下のユーザ全体に影響がある場合は、SCTP、NG Setup、Reset、AMF状態、過負荷処理などのノードレベル手順を先に確認します。1台のUEだけに影響がある場合は、そのUEのNGAP ID、NAS転送メッセージ、コンテキスト手順、PDUセッションリソースのシグナリングを追うべきです。

NGAP手順は、応答が必要かどうかによってClass 1とClass 2にも分類できます。Class 1手順には通常RequestとResponseが含まれ、Failure結果を伴う場合もあります。Class 2手順では、ピアからの手順レベルの応答は必要ありません。実際のトラブルシューティングでは、各NGAPメッセージのクラスを暗記するより、その手順が成功または失敗の結果を返す想定かどうかを確認する方が有用です。

N2はgNB起動からUE登録までどのように状態を構築するのか？

UEが1台も現れる前に、gNBが最初に解決すべきことは加入者登録ではありません。まずAMFと正常に通信できるかを確立する必要があります。

最初のステップは通常NG Setupです。gNBとAMFの間でSCTPアソシエーションが確立されると、gNBはNG Setup Requestを送信します。AMFが接続を受け入れると、NG Setup Responseを返します。AMFプール構成では、gNBが複数のAMFとN2関係を確立し、後のAMF選択に使用する情報を取得する必要がある場合があります。この時点で確立されているのはノードレベルの関係だけで、特定UEのコンテキストはまだ存在しません。

UEが登録を開始すると、シグナリングは次の段階に進みます。gNBはUEの最初のNASメッセージを受信すると、Initial UE Messageを使ってAMFへ転送できます。その後のUEとAMF間のNASシグナリングは通常、N2上のUplink NAS TransportとDownlink NAS Transportで運ばれます。重要なのは、gNBがNASのすべてのサービスロジックを解釈する必要はないという点です。多くのNASシグナリングでは、正しいUEコンテキストを識別し、NAS-PDUを適切なAMFへ届けることが主な役割です。

登録が進むにつれて、AMFはgNBにRAN側のUEコンテキストを確立させる必要があります。ここでInitial Context Setup RequestとInitial Context Setup Responseが現れます。Initial Context Setup Requestには、Allowed NSSAI、GUAMI、UE Security Capabilities、Mobility Restriction List、NAS-PDUなどの重要なUE関連情報を含めることができます。この段階では、gNBは単にNASシグナリングを転送するだけではなく、そのUEへのサービスを継続するために必要な状態を構築し始めています。

UEがデータ通信を開始するとき、NGAPはPDUセッションリソースをどう確立するのか？

登録が成功しても、UE用のすべてのユーザプレーンリソースがすでに利用可能という意味ではありません。UEがデータネットワークへアクセスするためにPDUセッションを確立する際、N2も対応するRANリソースの準備に関与します。

重要な手順の1つがPDU Session Resource Setupです。AMFはgNBへPDU Session Resource Setup Requestを送ります。このメッセージはPDUセッションとそのQoS Flowに関連する情報をNG-RANへ渡し、PDU Session ID、S-NSSAI、ユーザプレーントンネル情報、QoS Flow Listなどを含みます。gNBはローカル条件に応じて必要な無線側リソースを割り当て、たとえばQoS Flowに必要なDRBを設定し、N3ユーザプレーン接続を準備します。

リソース割り当てが完了すると、gNBはPDU Session Resource Setup ResponseをAMFへ送信し、正常に確立されたリソースを通知します。応答にはgNBのユーザプレーン情報や、正常に受け入れられたQoS Flowを含めることができます。

ここではN1、N2、N3の役割が混同されがちです。N1はNAS層のPDUセッション情報をUEへ運びます。N2はgNBが確立すべきRANおよびユーザプレーンリソースを調整します。N3はそれらのリソースが準備された後、実際のユーザプレーントラフィックを運びます。

そのため、PDUセッション失敗のトラブルシューティングは、NAS層がAcceptメッセージを返した時点で終えてはいけません。N2のPDU Session Resource Setup手順が正常に完了していなければ、UEはセッションパラメータを受け取っていてもユーザプレーンが動作していない可能性があります。

PDUセッション確立後もN2は動作し続ける

PDUセッションがアクティブになってもNGAPは停止しません。UEがネットワーク内にいる限り、状態やサービス条件の変化によって追加のN2手順がトリガーされることがあります。

UEが別のgNBへ移動すると、N2ベースまたはXnベースのハンドオーバーがトリガーされる場合があります。N2ハンドオーバーではHandover Required、Handover Request、Handover Request Acknowledge、Handover Command、Handover Notifyが使用されることがあります。新しい経路が確立されると、Path Switch Requestとその応答が続く場合があり、同時に送信元gNB上の古いUEコンテキストが解放されます。

UEがアイドル状態でダウンリンクトラフィックが到着すると、AMFはNGAPを介してNG-RANへPagingメッセージを送信でき、その後RANが無線側のページング手順を実行します。Pagingは典型的な一方向NGAP手順です。ネットワークがQoSやその他のRANリソースを調整する必要がある場合はPDU Session Resource Modifyがトリガーされ、セッションが不要になればPDU Session Resource Releaseが使用されます。したがって、PDUセッションのN2ライフサイクルにはSetupだけでなく、Modify、Release、Notifyおよび関連するIndication手順も含まれます。

UE関連のサービス手順に加えて、NG Reset、Error Indication、Overload Start、Overload Stop、AMF Status Indication、設定更新などのインターフェース管理メッセージを見ることもあります。これらは、問題が1台のUEだけに影響するのか、それともN2ノード関係のより広い変化を反映しているのかを判断する際に特に役立ちます。

NGAPパケットキャプチャをトラブルシューティングする最適な順序は？

NGAPには多数のメッセージがありますが、実際のトラブルシューティングで3GPPのメッセージ一覧を上から順に確認する必要はありません。ネットワーク状態が確立される順序に沿って追う方が効果的です。

最初にSCTPを確認します。gNBとAMF間のTransport Network Layer Associationが正しく確立されていなければ、その後に続くはずのNGAPサービス手順を分析してもほとんど意味がありません。

2番目にNG Setupを確認し、ノードレベルのN2関係が正常かを確かめます。NG Setupが失敗しているなら、いきなりUE登録のトラブルシューティングへ進むのは通常適切ではありません。

3番目に特定のUEを識別します。UE関連のNGAPメッセージには通常、関連するUE-NGAP-ID値が含まれます。パケット分析ではメッセージタイプだけでフィルタするのではなく、時間軸に沿って同じUE識別子を追跡します。

4番目にNASシグナリングが正しく転送されているかを確認します。Initial UE Message、Uplink NAS Transport、Downlink NAS Transportが連続したシーケンスになっているかを確認します。NAS-PDUがすでにAMFに到達しているのに応答がない場合と、gNBが最初からNASメッセージを届けていない場合では、調査の方向が大きく異なります。

5番目にUEコンテキストの確立を確認します。登録がInitial Context Setupまで進んでいる場合は、Request内のパラメータを確認し、Responseが正常に完了しているかを検証します。

6番目にPDUセッションリソースを確認します。UEが登録済みなのにデータネットワークへアクセスできない場合は、PDU Session Resource Setup Request/Responseと、返されたPDUセッションおよびQoS Flowのリソース結果に注目します。

モビリティ中に問題が発生する場合は、Handover、Path Switch、古いUEコンテキストの解放へ調査対象を移します。アイドル状態のUEへダウンリンクで到達できない場合はPagingに注目します。

SCTP → NG Setup → UE識別 → NAS → UEコンテキスト → PDUセッション → モビリティの順に追う方が、実際のエンジニアリングでは数十個のNGAPメッセージ名を暗記するよりはるかに効果的です。

よくある質問

NGAPと5G NASの関係は？

NGAPはgNBとAMF間のN2インターフェースで使用されるアプリケーション層プロトコルで、NASはUEと5Gコア間の制御シグナリングを運びます。多くのNASメッセージはNGAPメッセージ内にNAS-PDUとしてカプセル化され、gNBによってUEとAMFの間で転送されるため、2つのプロトコルは異なる層で動作します。

N2インターフェースはUEのインターネットトラフィックを運ぶのか？

いいえ。N2はUEデータの通常のユーザプレーン経路ではなく、コントロールプレーンシグナリングを運びます。ユーザトラフィックは通常N3を介してgNBとUPFの間で転送され、NGAPは関連するどのリソースをRANが確立、変更、または解放すべきかを指示します。

NG Setupが成功すればUEは正常に登録できるのか？

いいえ。NG Setupが確立するのはgNBとAMF間のノードレベルN2関係だけです。特定のUEが接続した後も、Initial UE Message、NAS転送、UEコンテキスト確立、その後のPDUセッションリソース手順を正常に完了する必要があります。

なぜNGAPのトラブルシューティングではメッセージタイプフィルタだけに頼ってはいけないのか？

1台のgNBは同時に多数のUEを処理でき、同じNGAPメッセージタイプが異なるユーザ向けに繰り返し現れます。メッセージ名だけでフィルタすると、無関係な手順を混同しやすくなります。UE単位のトラブルシューティングでは、UE-NGAP-ID値、メッセージ時刻、関連するNASまたはPDUセッションコンテキストを組み合わせて確認する必要があります。