NG Setup Procedure — gNBとAMFはN2確立時に何を交換するのか¶

学習目標¶

この章を読み終えると、次のことができるようになります。

• NG Setup が「UE単位」ではなく gNB⇔AMF間（non-UE-associated） の手続きであることを説明できる
• N2の立ち上がりを IP → SCTP → NG Setup → UE-associated NGAP の層に分けて説明できる
• NG Setup Request / Response / Failure の主要IE（Global RAN Node ID、Supported TA List、Served GUAMI List、Relative AMF Capacity、Cause、Time to Wait）の意味を説明できる
• 「SCTPはESTABLISHEDなのにRegistrationがAMFへ届かない」事象を、層ごとに切り分けられる

前提知識¶

• GUAMI / AMF Region / Set / Pointer — Served GUAMI List の中身
• N2 — NGAP over SCTP の基本
• 補助: NGAP辞典 / Network Slicing（S-NSSAI） / Registration（NG Setup後に流れるUE信号）

Why — なぜUEより先に「握手」が必要なのか¶

gNBとAMFの間にケーブルとIPがつながっただけでは、両者は相手のことを何も知りません。

• AMFは「このgNBは どのPLMNの、どのTracking Area を担当しているのか」を知らないと、Pagingを送る先を決められません。
• gNBは「このAMFは どのGUAMI を担当し、どれくらいの処理能力 があるのか」を知らないと、UEをどのAMFへ送るか決められません（前章）。

そこで、UEの信号を流す前に、gNBとAMFが お互いの自己紹介と能力を交換する 手続きが必要になります。それが NG Setup です（TS 38.413 Clause 8.7.1）。

例え話: NG Setupは「新しい支店（gNB）と本社（AMF）の開通手続き」です。支店は「私は○○支店で、この地域とこのサービスを担当します」と名乗り、本社は「私は本社の△△窓口で、担当番号はこれ、処理能力はこれくらいです」と返します。開通手続きが済むまで、お客さん（UE）の書類は回せません。

What — NG Setupの位置づけ¶

non-UE-associated な Class 1 手続き¶

NGAPの手続きは、特定UEに紐づく UE-associated と、ノード間全体に関わる non-UE-associated に分かれます。NG Setupは後者です。また、要求に対して応答（成功/失敗）が返る Class 1 手続きです（TS 38.413 Clause 8.1）。

N2は4層で立ち上がる¶

flowchart TD
    L1["① IP 到達性
(ルーティング / VRF / FW)"] --> L2["② SCTP Association
INIT → INIT ACK → COOKIE ECHO → COOKIE ACK"]
    L2 --> L3["③ NG Setup
NGAP non-UE-associated"]
    L3 --> L4["④ UE-associated NGAP
Initial UE Message 等"]
    L4 --> L5["⑤ NAS手続き
Registration / Authentication / Security"]

N2のSCTPに関する規定（TS 38.412 Clause 7）¶

How — 交換される情報¶

Call Flow¶

sequenceDiagram
    participant gNB
    participant AMF
    gNB->>AMF: SCTP INIT
    AMF-->>gNB: SCTP INIT ACK
    gNB->>AMF: SCTP COOKIE ECHO
    AMF-->>gNB: SCTP COOKIE ACK
    Note over gNB,AMF: SCTP Association ESTABLISHED（まだN2は未確立）
    gNB->>AMF: NG Setup Request
(Global RAN Node ID, RAN Node Name, Supported TA List, Default Paging DRX)
    AMF->>AMF: PLMN等を自身の設定と照合
    alt 成功
        AMF-->>gNB: NG Setup Response
(AMF Name, Served GUAMI List, Relative AMF Capacity, PLMN Support List)
        Note over gNB,AMF: N2 Ready → UE-associated NGAP を流せる
    else 失敗
        AMF-->>gNB: NG Setup Failure
(Cause, Time to Wait)
        Note over gNB: Time to Wait があれば、その時間以上待ってから再試行
    end

NG Setup Request — gNB → AMF（TS 38.413 Clause 9.2.6.1）¶

gNBが「自分は誰で、何を担当しているか」を伝えます。

主要IEの抜粋であり、網羅ではありません（Releaseにより任意IEが追加されます）。

Global RAN Node ID¶

Global RAN Node ID (CHOICE)
├─ Global gNB ID
│   ├─ PLMN Identity
│   └─ gNB ID        ← 22〜32 bit（ビット長はオペレータが選ぶ）
├─ Global ng-eNB ID
└─ Global N3IWF ID   （Releaseにより TNGF / TWIF / W-AGF 等が追加）

gNB IDのビット長は22〜32 bitの範囲でオペレータが選び、NR Cell Identity（36 bit）の上位部分 になります（TS 38.413 Clause 9.3.1.6、TS 38.300 Clause 8.2。いずれも節番号は要確認）。Traceで「どのgNBからのNG Setupか」を特定する最重要IEです。

Supported TA List — この章で一番大事なIE¶

Supported TA List
└─ Supported TA Item（TAごと）
    ├─ TAC
    └─ Broadcast PLMN List
        └─ Broadcast PLMN Item（PLMNごと）
            ├─ PLMN Identity
            └─ TAI Slice Support List
                ├─ S-NSSAI #1  (SST, SD)
                └─ S-NSSAI #2

gNBは「このTAでは、このPLMNの、このS-NSSAIを提供できます」とAMFへ宣言します。

なぜ「List」なのか。 Tracking Area は複数Cellを束ねた単位で、Registration Area（TAI List）の構成単位です（TS 23.501 Clause 5.3.2.3）。TACは Cellごと（厳密にはSIB1内のPLMN-IdentityInfoごと）にSIB1でBroadcastされます（TS 38.331 Clause 6.2.2 / Clause 6.3.2、要確認）。1台のgNBが持つCellが 異なるTAに属することがある ため、gNBは自Cellが属するTAを1つずつ列挙して申告します。

gNB-1
├─ Cell A ─┐
├─ Cell B ─┴─ TAC 0x000001 ─┐
└─ Cell C ─── TAC 0x000002 ─┴─► Supported TA List
                                 ├─ Supported TA Item (TAC 0x000001)
                                 └─ Supported TA Item (TAC 0x000002)

この申告内容と、各CellのSIB1でBroadcastしているTACが食い違っていると、AMFが把握するTAと、UEが在圏Cellで見るTAがずれます（Paging・Registration Areaへの影響は Tracking Area / TAI / Registration Area 参照）。TAとCellの関係の詳細もそちらで扱います。

Tracking Area は、UEのRegistration Area（TAI List）を構成する単位です。AMFはこのリストから「どのgNBがどのTAを担当しているか」を覚え、CM-IDLEのUEへのPagingを、そのUEのRegistration Areaに含まれるTAを担当するgNBへ送ります（TS 38.413 Clause 8.5 / TS 23.502 Clause 4.2.3.3、要確認）。

AMFは何を確認するか¶

具体的に明示されている拒否条件は、gNBが示したPLMN（Rel-16以降はSNPNを含む）のどれもAMFが識別できない場合 です（TS 38.413 Clause 8.7.1.4、要確認）。それ以外は、「AMFが受け入れられなければ NG Setup Failure を返す」という汎用規定（Clause 8.7.1.3）の下でAMF実装次第になります。

flowchart TD
    R["NG Setup Request 受信"] --> P{"示されたPLMNのいずれかを
AMFが扱える?"}
    P -- "No" --> F["NG Setup Failure
(Cause: Unknown PLMN /
Unknown PLMN or SNPN)"]
    P -- "Yes" --> O{"TAC / S-NSSAI 等が
AMF設定と整合?"}
    O -- "判断はAMFの実装・設定次第" --> S["NG Setup Response
または Failure"]

NG Setup Response — AMF → gNB（TS 38.413 Clause 9.2.6.2）¶

主要IEの抜粋であり、網羅ではありません（Releaseにより任意IEが追加されます）。

Relative AMF Capacity — CPU使用率ではない¶

Relative AMF Capacity は、NG-RANがAMFを選ぶときの 重み（Weight Factor） です（TS 23.501 Clause 5.19.3、節番号は要確認）。新規UEは、この値に比例した確率で各AMFへ振り分けられます。

AMF-1: Relative AMF Capacity = 255
AMF-2: Relative AMF Capacity = 128
→ 新規UEはおおむね 2:1 で振り分けられる（振り分けの細部はgNB実装依存）

• CPU使用率や負荷のリアルタイム値ではありません。オペレータがAMFの能力に応じて設定する 相対値 です。値は AMF Configuration Update（TS 38.413 Clause 8.7.3）で後から変更できます。
• 既存UEには効きません。5G-GUTI / 5G-S-TMSI を持つUEは、GUAMIによって前回のAMFへ戻されるためです。

NG Setup Failure — AMF → gNB（TS 38.413 Clause 9.2.6.3）¶

Time to Wait が含まれている場合、gNBはその時間が経過するまで同じAMFへNG Setupを再送してはいけません（TS 38.413 Clause 8.7.1.3）。これにより、AMF再起動直後などに多数のgNBが一斉に再試行してAMFを圧迫することを防ぎます。

NG Setup後の設定変更¶

NG Setupで交換した情報は、N2を張り直さずに更新できます。

NG SetupからUE Registrationへ¶

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    Note over gNB,AMF: Step 1: SCTP Association
    Note over gNB,AMF: Step 2: NG Setup Request / Response
    UE->>gNB: RRC接続 + Registration Request (NAS)
    gNB->>AMF: Initial UE Message (NAS-PDU)
    Note over AMF: Step 3: UE単位の手続きが始まる
(Authentication / Security / Registration Accept)

Registration で最初に登場する Initial UE Message の前には、必ず SCTP → NG Setup が済んでいます。gNBがUEの送り先AMFを選ぶときに使う Served GUAMI List と Relative AMF Capacity も、このNG Setupで受け取った情報です。

Packet Analysis (Wireshark)¶

Display Filter¶

NGAPの procedureCode の数値はディセクタ・版により表示が異なる場合があるため、本ページでは断定しません。GUIのプロトコル階層表示でメッセージ名（NGSetupRequest 等）を確認するのが確実です。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はテスト用PLMN（001-01）の架空例です（実キャプチャではありません）。

NGAP NGSetupRequest
 ├─ GlobalRANNodeID
 │   └─ globalGNB-ID
 │       ├─ pLMNIdentity: 001-01
 │       └─ gNB-ID: 0x000001 (22 bits)
 ├─ RANNodeName: gnb-lab-01
 ├─ SupportedTAList
 │   └─ SupportedTAItem
 │       ├─ tAC: 0x000001
 │       └─ broadcastPLMNList
 │           └─ BroadcastPLMNItem
 │               ├─ pLMNIdentity: 001-01
 │               └─ tAISliceSupportList
 │                   └─ s-NSSAI: sST=1, sD=0x010203
 └─ DefaultPagingDRX: v128

見る順番¶

flowchart LR
    A["① IP
ping / 経路"] --> B["② SCTP
4-way handshake
ABORT/SHUTDOWNの有無"]
    B --> C["③ NG Setup
Request → Response / Failure"]
    C --> D["④ UE-associated NGAP
Initial UE Message"]

「SCTPはESTABLISHEDなのにRegistration RequestがAMFに来ない」ときは、UEを疑う前に ③ NG Setupが成功しているか を確認します。

比較表を作る¶

NG Setup Failure の解析では、gNBが送った値とAMFの設定を左右に並べる のが効率的です。

Trouble Shooting¶

Causeのカテゴリから当たりを付ける¶

NG Setup Failure を見たら、まず Cause のカテゴリ を見て「設定の不一致か / AMFの状態か / メッセージ自体の問題か」を分けます。Cause の値の一覧は TS 38.413 Clause 9.3.1.2 です（Cause辞典 も参照）。

SCTP Association と NG接続を混同しない¶

             IP-A ────────── IP-C
            /                    \
gNB ===== SCTP Association ====== AMF      ← 1つのAssociationが複数IPパスを持てる（マルチホーミング）
            \                    /
             IP-B ────────── IP-D

• SCTPのマルチホーミング は、1つのAssociationの中で複数のIPパスを持つ仕組みで、片方のパスが落ちてもAssociationは維持されます（RFC 9260）。
• 複数のTNL association は、gNB⇔AMF間にSCTP Association自体を複数持つ仕組みです（TS 38.412 Clause 7、TS 38.413 Clause 8.7.3）。
• どちらも NGAPのNG接続（NG Setupで確立した関係）とは別の層 です。Troubleshootingでは「IP → SCTP → NGAP（NG Setup）」と層を分けて考えます。

3GPP仕様とVendor実装の境界¶

NG Setupが失敗したときは、3GPPの信号の問題か / 伝送・SCTPの問題か / Vendor実装の問題か を分けて考えます。

EPC（4G）との比較¶

骨格はS1 Setupとほぼ同じで、5Gでは スライス（S-NSSAI）情報 と 非3GPPアクセスノード（N3IWF等） が加わった点が大きな違いです。

3GPP Specification¶

Summary¶

• NG Setup は gNB⇔AMF間の non-UE-associated な手続きで、SCTP確立後に最初に行うNGAP手続き
• N2の立ち上がりは IP → SCTP → NG Setup → UE-associated NGAP。「SCTP ESTABLISHED」「NG Setup成功」「Registration成功」は別の段階
• gNBは Global RAN Node ID / Supported TA List（TAC・PLMN・S-NSSAI） で自己紹介する
• AMFは Served GUAMI List / Relative AMF Capacity / PLMN Support List を返し、gNBはこれをAMF選択に使う
• 仕様が明示する拒否条件は PLMN不一致。TAC・スライス不一致の扱いは実装依存
• 失敗時は Cause（カテゴリで「設定不一致 / AMFの状態 / メッセージ符号化」を切り分け）と Time to Wait を見る。NG Setupをやり直すと、UE Retention に合意していなければ UE Contextが消える

理解度チェック¶

Next Step¶

• NG Setup Response で受け取る GUAMI の中身 → GUAMI / AMF Region / Set / Pointer
• NG Setup後に流れるUE信号 → Registration / SUPI / SUCI / 5G-GUTI
• Supported TA List の TAC が効いてくる仕組み → Tracking Area / TAI / Registration Area / Paging / Mobility Registration Update
• S-NSSAI とスライス選択 → Network Slicing
• N2インタフェースの全体像 → N2 / NGAP辞典