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信号)
この章の焦点(Level ∞ マニアック)
N2ページでは「NG SetupはN2確立の握手」と一言で紹介しています。この章では、握手で何を交換し、AMFが何を確認し、失敗したらどう見えるか を、IEレベルとTrace解析の観点で掘り下げます。
Why — なぜUEより先に「握手」が必要なのか¶
gNBとAMFの間にケーブルとIPがつながっただけでは、両者は相手のことを何も知りません。
- AMFは「このgNBは どのPLMNの、どのTracking Area を担当しているのか」を知らないと、Pagingを送る先を決められません。
- gNBは「このAMFは どのGUAMI を担当し、どれくらいの処理能力 があるのか」を知らないと、UEをどのAMFへ送るか決められません(前章)。
そこで、UEの信号を流す前に、gNBとAMFが お互いの自己紹介と能力を交換する 手続きが必要になります。それが NG Setup です(TS 38.413 §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 §8.1)。
| 分類 | 例 |
|---|---|
| non-UE-associated | NG Setup、RAN Configuration Update、AMF Configuration Update、NG Reset、AMF Status Indication |
| UE-associated | Initial UE Message、Initial Context Setup、PDU Session Resource Setup、UE Context Release |
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"]
| 層 | 規定 | 成功の目安 |
|---|---|---|
| ① IP | — | 双方のN2アドレスへ到達できる |
| ② SCTP | RFC 9260(旧RFC 4960)、N2での使い方は TS 38.412 §7 | Association が ESTABLISHED |
| ③ NG Setup | TS 38.413 §8.7.1 | NG Setup Response を受信 |
| ④ UE-associated NGAP | TS 38.413 §8.6.1(Initial UE Message) | Initial UE Message がAMFへ届く |
「SCTP ESTABLISHED = N2が使える」ではない
SCTPはあくまで運び手です。その上でNG Setupが成功して初めて、UE信号を流せる状態になります。TS 38.413 §8.7.1.1 は、NG Setupを TNL association(SCTP)が使用可能になった後に最初に起動するNGAP手続き と定めています(枝番は要確認)。
N2のSCTPに関する規定(TS 38.412 §7)¶
| 項目 | 内容 |
|---|---|
| SCTPを張る側 | NG-RANノード(gNB) が確立を開始する |
| 宛先ポート | 38412 |
| Payload Protocol Identifier | NGAP用の値(60) |
| ストリーム | non-UE-associated 手続き専用のストリームを1組予約する。UE-associated 手続き用にも少なくとも1組を予約する |
| 複数のSCTP Association | gNB⇔AMF間に複数のTNL association を持てる(AMF Configuration Update で追加・削除を指示できる、TS 38.413 §8.7.3) |
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 §9.2.6.1)¶
gNBが「自分は誰で、何を担当しているか」を伝えます。
| IE | 必須/任意 | 意味 |
|---|---|---|
| Global RAN Node ID | 必須 | gNBの識別子(PLMN + gNB ID)。ng-eNB / N3IWF 等の場合もここで区別 |
| RAN Node Name | 任意 | 人間向けの名前。Trace解析で便利 |
| Supported TA List | 必須 | 担当するTAと、TAごとのPLMN・S-NSSAI |
| Default Paging DRX | 必須 | UE個別の指定が無い場合に使うPaging周期 |
| UE Retention Information | 任意 | UE contextを保持したまま設定を再交換するかどうかの合意に使う |
主要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 §9.3.1.6、TS 38.300 §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へ宣言します。
| 用語 | 意味 | 規定 |
|---|---|---|
| TAC(Tracking Area Code) | Tracking Area を識別するコード。5GSでは24 bit | TS 23.003 §19.4.2.3(要確認) |
| TAI(Tracking Area Identity) | PLMN ID + TAC | TS 23.003 §19.4.2.3(要確認) |
| S-NSSAI | Network Sliceの識別子。SST(8 bit、必須)+ SD(24 bit、任意) | TS 23.003 §28.4.2、TS 23.501 §5.15.2.1 |
Tracking Area は、UEのRegistration Area(TAI List)を構成する単位です。AMFはこのリストから「どのgNBがどのTAを担当しているか」を覚え、CM-IDLEのUEへのPagingを、そのUEのRegistration Areaに含まれるTAを担当するgNBへ送ります(TS 38.413 §8.5 / TS 23.502 §4.2.3.3、要確認)。
AMFは何を確認するか¶
具体的に明示されている拒否条件は、gNBが示したPLMN(Rel-16以降はSNPNを含む)のどれもAMFが識別できない場合 です(TS 38.413 §8.7.1.4、要確認)。それ以外は、「AMFが受け入れられなければ NG Setup Failure を返す」という汎用規定(§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"]
TAC・スライス不一致の扱いは実装依存
「TACがAMFのService Areaに無い」「S-NSSAIが一致しない」ときに NG Setupを拒否するか、受け入れて後続手続きで扱うか は、仕様で一律に決まっているわけではなく AMFの実装・設定依存 です。実機での挙動は製品ドキュメントとTraceで確認してください。
NG Setup Response — AMF → gNB(TS 38.413 §9.2.6.2)¶
| IE | 必須/任意 | 意味 |
|---|---|---|
| AMF Name | 必須 | AMFの名前 |
| Served GUAMI List | 必須 | このAMFが担当するGUAMI(任意で Backup AMF Name 付き)。前章参照 |
| Relative AMF Capacity | 必須 | 他AMFと比べた相対的な処理能力(0〜255) |
| PLMN Support List | 必須 | AMFが扱うPLMNと、PLMNごとの Slice Support List(S-NSSAI) |
| Criticality Diagnostics | 任意 | 受信メッセージのIEに問題があった場合の診断情報 |
| UE Retention Information | 任意 | UE context保持の合意(Request側と対になる) |
主要IEの抜粋であり、網羅ではありません(Releaseにより任意IEが追加されます)。
Relative AMF Capacity — CPU使用率ではない¶
Relative AMF Capacity は、NG-RANがAMFを選ぶときの 重み(Weight Factor) です(TS 23.501 §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 §8.7.3)で後から変更できます。
- 既存UEには効きません。5G-GUTI / 5G-S-TMSI を持つUEは、GUAMIによって前回のAMFへ戻されるためです。
Relative AMF Capacity = 0 の扱い
保守時に値を 0 にして「新規UEを寄せない」運用が語られることがあります。ただし、0のときにNG-RANが選択対象から外すことを仕様がどこまで規定しているかは 要確認、実際の挙動は gNB実装依存 です。また0にしても 既存UEが即座に別AMFへ移るわけではありません。既存UEを移すには、AMF Status Indication(Unavailable GUAMI)や負荷再分散の仕組みを組み合わせます(前章参照)。
NG Setup Failure — AMF → gNB(TS 38.413 §9.2.6.3)¶
| IE | 必須/任意 | 意味 |
|---|---|---|
| Cause | 必須 | 失敗理由(TS 38.413 §9.3.1.2。Radio Network / Transport / NAS / Protocol / Miscellaneous の分類) |
| Time to Wait | 任意 | gNBが再試行するまでに待つべき最低時間 |
| Criticality Diagnostics | 任意 | IE単位の診断情報 |
Time to Wait が含まれている場合、gNBはその時間が経過するまで同じAMFへNG Setupを再送してはいけません(TS 38.413 §8.7.1.3)。これにより、AMF再起動直後などに多数のgNBが一斉に再試行してAMFを圧迫することを防ぎます。
NG Setupのやり直しでUE Contextが消える場合がある
NG Setupは、両ノードの既存のアプリケーションレベル設定を受信した内容で置き換えます。さらに、NG-RANノードとAMFがUE contextの保持に合意しない場合(UE Retention Information IE で合意しない場合)は、既存のNGAP UE-related contextと関連する信号接続を、NG Resetと同様に消去します(TS 38.413 §8.7.1.1、枝番は要確認)。運用中にNG Setupがやり直されると、配下UEのN2上のContextが失われ得る点に注意してください。また、NG-RANノードが保持するAMFの過負荷状態もクリアされます(同節)。
NG Setup後の設定変更¶
NG Setupで交換した情報は、N2を張り直さずに更新できます。
| 手続き | 方向 | 用途 | 規定 |
|---|---|---|---|
| RAN Configuration Update | gNB → AMF | Supported TA List 等の変更 | TS 38.413 §8.7.2 |
| AMF Configuration Update | AMF → gNB | Served GUAMI List / Relative AMF Capacity / PLMN Support List / TNL association の変更 | TS 38.413 §8.7.3 |
| AMF Status Indication | AMF → gNB | Unavailable GUAMI の通知 | TS 38.413 §8.7.6 |
| NG Reset | 双方向 | UE-associated な接続の全部または一部をリセット | TS 38.413 §8.7.4 |
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¶
| フィルタ | 用途 |
|---|---|
sctp |
SCTP全体 |
sctp.port == 38412 |
N2のSCTPに絞る |
sctp.chunk_type in {1 2 10 11} |
4-way handshake(INIT / INIT ACK / COOKIE ECHO / COOKIE ACK。chunk type値はRFC 9260) |
sctp.chunk_type == 6 |
ABORT(Associationの異常切断) |
sctp.data_payload_proto_id == 60 |
NGAPを運ぶDATA chunk(PPID=60。フィールド名はWiresharkの版で要確認) |
ngap |
NGAP全体 |
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の設定を左右に並べる のが効率的です。
| 項目 | gNB(NG Setup Request) | AMF設定 | 判定 |
|---|---|---|---|
| PLMN | 001-01 | 001-01 | OK |
| TAC | 0x000001 | 0x000002 | 要確認 |
| S-NSSAI | SST=1, SD=0x010203 | SST=1(SDなし) | 要確認(SD有無の一致) |
Trouble Shooting¶
| 症状 | 想定原因 | 確認ポイント | ログ | Packet | 解決方法 |
|---|---|---|---|---|---|
| SCTP INITに応答がない | IP到達性・FW・ポート38412がふさがれている | 経路、ACL、AMFのSCTP待受 | gNB/AMFのSCTPログ | sctp |
経路・FW設定を修正 |
| SCTPは確立するがNG Setup Requestが出ない | gNB側のNGAP設定未完了 | gNBのAMF接続設定 | gNBログ | ngap |
gNB設定を見直す |
| NG Setup Failure(Unknown PLMN 系。Rel-16以降は Unknown PLMN or SNPN、要確認) | PLMNの不一致 | Request内PLMNとAMFのPLMN設定 | AMFログ | ngap(Cause) |
PLMN設定を統一 |
| NG Setup Failure(その他のCause) | TAC・スライス不一致、IE不備など(どれで拒否するかは実装依存) | 上の比較表、Criticality Diagnostics | AMFログ | ngap |
設定・ソフトウェア版を確認(要検証) |
| NG Setup成功後もUEがAMFへ来ない | gNBのAMF選択(Relative AMF Capacity=0 等)、別AMFへの振り分け | NG Setup Response / AMF Configuration Update の値 | gNBログ | ngap |
容量値・GUAMI設定を確認 |
| NG Setupが繰り返され、UEが切断される | SCTPの再確立ループ(UE Retention未合意なら、NG SetupのたびにUE Contextが消える) | SCTP ABORT / HEARTBEAT 失敗の有無 | 両側のSCTPログ | sctp.chunk_type == 6 |
伝送路・マルチホーミング設定を確認 |
| 再試行がすぐに来ない | Time to Wait による待機 | Failure内の Time to Wait | gNBログ | ngap |
仕様どおりの動作。AMF側の原因を解消 |
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 §7、TS 38.413 §8.7.3)。
- どちらも NGAPのNG接続(NG Setupで確立した関係)とは別の層 です。Troubleshootingでは「IP → SCTP → NGAP(NG Setup)」と層を分けて考えます。
3GPP仕様とVendor実装の境界¶
| 3GPPが定義するもの | Vendor / 運用が決めるもの |
|---|---|
| NG Setup Request / Response / Failure とそのIE | show ngap peer / show n2 status などのCLI |
| SCTPの使い方(ポート38412、PPID、gNBが確立を開始) | N2用VIP、Keepalived、LB、N2 VRFの構成 |
| PLMN不一致時の拒否、Time to Wait の意味 | TAC・スライス不一致時に拒否するかどうか |
| Relative AMF Capacity の意味(相対的な重み) | 容量値の決め方、gNBの具体的な選択アルゴリズム |
| NG Setup時のUE Context消去と、UE Retention Informationによる保持条件 | SCTP処理を担うPod / コンテナの冗長構成 |
NG Setupが失敗したときは、3GPPの信号の問題か / 伝送・SCTPの問題か / Vendor実装の問題か を分けて考えます。
EPC(4G)との比較¶
| 項目 | 4G EPC(S1 Setup) | 5GC(NG Setup) |
|---|---|---|
| 手続き | S1 Setup(TS 36.413 §8.7.3) | NG Setup(TS 38.413 §8.7.1) |
| インタフェース / ポート | S1-MME / SCTP 36412 | N2 / SCTP 38412 |
| RAN側の識別子 | Global eNB ID | Global RAN Node ID(gNB / ng-eNB / N3IWF 等) |
| 担当エリア | Supported TAs(TAC + Broadcast PLMNs) | Supported TA List(TAC + PLMN + S-NSSAI) |
| コア側の識別子 | Served GUMMEIs | Served GUAMI List |
| 容量値 | Relative MME Capacity | Relative AMF Capacity |
| スライス情報 | なし | TAI Slice Support List / PLMN Support List |
| 失敗時 | S1 Setup Failure(Cause, Time to wait) | NG Setup Failure(Cause, Time to Wait) |
骨格はS1 Setupとほぼ同じで、5Gでは スライス(S-NSSAI)情報 と 非3GPPアクセスノード(N3IWF等) が加わった点が大きな違いです。
3GPP Specification¶
| 仕様 | 節 | 内容 |
|---|---|---|
| TS 38.413 | §8.1 | NGAP手続きの分類(Class 1 / Class 2) |
| TS 38.413 | §8.7.1 | NG Setup(§8.7.1.1 概要 / §8.7.1.2 成功 / §8.7.1.3 失敗 / §8.7.1.4 異常系。枝番は要確認) |
| TS 38.413 | §8.7.2 / §8.7.3 / §8.7.4 / §8.7.6 | RAN Configuration Update / AMF Configuration Update / NG Reset / AMF Status Indication |
| TS 38.413 | §9.2.6.1 / §9.2.6.2 / §9.2.6.3 | NG Setup Request / Response / Failure のメッセージ定義 |
| TS 38.413 | §9.3.1.2 | Cause |
| TS 38.413 / TS 23.502 | §8.5 / §4.2.3.3 | Paging(Supported TA List の利用先。要確認) |
| TS 38.412 | §7 | N2のSCTP(ポート、PPID、ストリーム、TNL association) |
| TS 23.003 | §19.4.2.3 / §28.4.2 | TAI・TAC / S-NSSAI の形式(要確認を含む) |
| TS 23.501 | §5.15.2.1 / §5.19.3 | S-NSSAI / AMF Load Balancing(Weight Factor。要確認を含む) |
| TS 36.413 | §8.7.3 | S1 Setup(EPC比較用) |
| RFC 9260 | — | SCTP(RFC 4960 を置き換え) |
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 と Time to Wait を見る。NG Setupをやり直すと、UE Retention に合意していなければ UE Contextが消える
理解度チェック¶
Q1. gNB⇔AMF間のSCTP AssociationはESTABLISHEDですが、NG Setup RequestのPLMN/TACとAMF側のService Area設定に重大な不整合があります。最も適切な説明はどれか。A. SCTPがESTABLISHEDなのでNG Setupも必ず成功する / B. AMFは必ずNG Setup Responseを返し、Registration時に初めて不整合を確認する / C. Transport Layerが正常でも、NGAP LayerのNG Setupは失敗し得る / D. PLMN/TACはPFCPでSMFとUPFが確認するため、NG Setupには影響しない
正解: C。SCTPは運び手であり、その上のNGAPで設定の整合性が確認されます。PLMNがどれも一致しなければ、AMFはNG Setup Failureを返します(TS 38.413 §8.7.1)。TAC不一致で拒否するかどうかはAMFの実装依存ですが、「必ず成功する」(A)、「必ずResponseを返す」(B)は誤りです。PFCP(D)はN4(SMF⇔UPF)のプロトコルで、NG Setupとは無関係です。
Q2. Relative AMF Capacity を 255 から 0 に変更しました。既存の登録済みUEはどうなりますか。
即座に別AMFへ移るわけではありません。Relative AMF Capacityが効くのは、主にgNBが既存の識別子なしでAMFを選ぶ新規UEです。5G-GUTI / 5G-S-TMSI を持つUEは、GUAMIによって前回のAMFへ戻されます。既存UEを移すには、AMF Status Indication(Unavailable GUAMI)や負荷再分散の仕組みを組み合わせます。また、0のときの扱いは gNB実装依存です。
Q3. NG Setup Failure に Time to Wait が含まれていました。gNBはどう振る舞うべきですか。また、その目的は何ですか。
Time to Wait で示された時間が経過するまで、同じAMFへNG Setupを再送しません(TS 38.413 §8.7.1.3)。AMFの再起動直後などに多数のgNBが一斉に再試行し、AMFを圧迫することを防ぐためです。
Q4. 運用中のgNB⇔AMF間でNG Setupがやり直されました。配下UEへの影響は何ですか。
gNBとAMFが UE Retention Information でUE contextの保持に合意していなければ、NG Setupは既存のNGAP UE-related contextと関連する信号接続を、NG Resetと同様に消去します(TS 38.413 §8.7.1.1、枝番は要確認)。その場合、配下UEのN2上のContextは失われ、UEは信号接続を張り直すことになります。SCTPの再確立ループが起きていると、この現象が繰り返されます。
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辞典