PDU Session Establishment 深掘り — N1 SM / N2 SM / N3 / N4 はどう連携してUser Planeを作るのか¶

学習目標¶

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

• Registration と PDU Session Establishment が別の手続き であることを説明できる
• N1 SM 情報（UE向け） と N2 SM 情報（RAN向け） の違いと、どちらも AMFが中継する 理由を説明できる
• SMFがUPFを PFCP Session Establishment → Modification の2段構え で設定する理由（gNB側TEIDが後から分かる）を説明できる
• N3 Tunnel の UL側（UPF F-TEID）とDL側（gNB F-TEID） が、どのメッセージで誰から誰へ渡るかを追跡できる
• PDU Session が確立できない／確立したのにDataが流れない場合に、N1 → N11 → N4 → N2 → N4 → N3 の順で切り分けられる

前提知識¶

• PDU Session Establishment — 手続き全体の基本（本章はその「配線」部分を深掘りします）
• CM-IDLE / CM-CONNECTED と Service Request — 前章。既にあるPDU Session のN2/N3をService Requestで再確立する流れ。本章は一段戻って、そのN3が 最初にどう作られるか を扱います
• Service Request — CM-IDLEからN2/N3を再確立する手続き。N2 SM 情報の流れは本章と共通です
• 補助: N1 / N2 / N3 / N4 / N11

Why — Registrationが成功しても通信できないのはなぜか¶

PDU Session は「UE と Data Network（DN）の間で PDU Connectivity Service を提供する関連付け（Association）」と定義されています（TS 23.501 Clause 3.1、要確認）。User Plane の経路として見ると次の形です。

UE ──(無線)── gNB ──N3（GTP-U）── UPF ──N6── DN（Internet / IMS / 企業網）

この経路を成立させるための論理セッションを作るのが PDU Session Establishment です。

Registration は「UEを5GSへ登録する」手続き、PDU Session Establishment は「UEがData Network（DN）と通信するための論理セッションを作る」手続きです。両者は別物です（TS 23.501 Clause 5.6.1）。

Registration 成功
   → UEは5GCに登録済み（5GMM-REGISTERED）
   → しかし PDU Session が無ければ User Plane は無い
   → Internet通信はまだできない

例え話: Registration は「ビルの入館証をもらう」こと、PDU Session は「目的のフロア（DN）への専用エレベーターを手配する」ことです。入館証があっても、エレベーターが無ければ目的地には行けません。

What — PDU Session を識別する3つの値¶

PDU Session ID¶

各PDU Sessionは、UE内で PDU Session ID によって識別されます。1つのUEが複数のPDU Sessionを同時に持てます。

UE
├─ PDU Session ID = 1   DNN = internet   S-NSSAI = SST 1
└─ PDU Session ID = 2   DNN = ims        S-NSSAI = SST 1

DNN（Data Network Name）¶

UEが どのData Networkへ接続したいか を示します。4G EPC の APN に相当する概念です（定義は TS 23.501 Clause 3.1、形式は TS 23.003 Clause 9A、要確認）。

DNN = internet    → Internet
DNN = ims         → IMS（VoNR等）
DNN = enterprise  → 企業網

S-NSSAI¶

どのNetwork Sliceで 接続するかを示します（SST + 任意のSD。TS 23.003 Clause 28.4.2、要確認）。

S-NSSAI (SST = 1, SD = 010203)  +  DNN = internet
              ↓
「どのSliceで、どのDNへ」接続するか
              ↓
SMF Selection / UPF Selection の入力になる

UEが Request で DNN / S-NSSAI を省略した場合、網側は加入者データ上の既定値（default DNN / default S-NSSAI）を使い得ます（TS 23.502 Clause 4.3.2.2.1、要確認）。

What — 誰が何をするのか¶

AMFは Mobility / Access側の司令塔、SMFは PDU Session の司令塔、UPFは User Packetを運ぶ実体 です（TS 23.501 Clause 6.2.1 / Clause 6.2.2 / Clause 6.2.3）。

What — N1 SM 情報と N2 SM 情報¶

5GSMメッセージは5GMMメッセージに包まれて運ばれる¶

PDU SESSION ESTABLISHMENT REQUEST は 5GSM（5G Session Management） メッセージです。UEとSMFの間に直接のNAS接続は無いため、UEはこれを 5GMM の UL NAS TRANSPORT の Payload container に入れてAMFへ送ります（TS 24.501 Clause 8.2.10 / Clause 8.3.1）。

NGAP Uplink NAS Transport (N2)
└─ NAS-PDU
    └─ UL NAS TRANSPORT（5GMM）
        ├─ Payload container type = N1 SM information
        ├─ PDU session ID = 1
        ├─ Request type = initial request
        ├─ S-NSSAI / DNN（任意）
        └─ Payload container
            └─ PDU SESSION ESTABLISHMENT REQUEST（5GSM）
                ├─ PDU session ID = 1
                ├─ PTI
                └─ PDU session type 等

AMFは外側（UL NAS TRANSPORT）のPDU session ID・S-NSSAI・DNNを見てSMFを選び、内側の5GSMメッセージは N1 SM container として そのまま SMFへ渡します（TS 23.502 Clause 4.3.2.2.1）。

方向ごとの整理¶

UE  ──N1──►  AMF  ──N11──►  SMF        N1 SM（UE向け）
gNB ◄──N2──  AMF  ◄──N11──  SMF        N2 SM（RAN向け）

覚え方は、N1 SM = SMF ⇔ UE 用、N2 SM = SMF ⇔ RAN 用、どちらもAMFが運ぶ です。SMFがgNBへ直接NGAPを送ることはありません。

How — End-to-End Call Flow¶

以下は TS 23.502 Clause 4.3.2.2.1（UE-requested PDU Session Establishment、非ローミング／Local Breakout）の主要部分を簡略化したものです。UDM・PCF・二次認証・Charging 等のステップは省略しています（step 番号は版による差があるため 要確認）。

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF
    UE->>AMF: (1) UL NAS Transport [PDU Session Establishment Request]
    Note over AMF: (2) SMF Selection（S-NSSAI / DNN 等、NRF経由も可）
    AMF->>SMF: (3) Nsmf_PDUSession_CreateSMContext Request [N1 SM container]
    Note over SMF: (4) UDM連携（省略）
    SMF-->>AMF: (5) CreateSMContext Response
    Note over SMF: PCF連携・二次認証（省略）・(8) UPF Selection・UE IPアドレス割当
    SMF->>UPF: (10a) PFCP Session Establishment Request [Create PDR/FAR/QER/URR]
    UPF-->>SMF: (10b) PFCP Session Establishment Response [UPF側 F-TEID 等]
    SMF->>AMF: (11) Namf_Communication_N1N2MessageTransfer [N1 SM: Accept, N2 SM: UPF N3 F-TEID / QoS]
    AMF->>gNB: (12) NGAP PDU Session Resource Setup Request [NAS-PDU: Accept, N2 SM 情報]
    gNB->>UE: (13) RRC Reconfiguration [NAS: PDU Session Establishment Accept]
    gNB->>AMF: (14) NGAP PDU Session Resource Setup Response [N2 SM: gNB N3 F-TEID]
    Note over UE,UPF: First Uplink Data（UE → gNB → UPF。図上は step 14 の後、要確認）
    AMF->>SMF: (15) Nsmf_PDUSession_UpdateSMContext Request [N2 SM 情報]
    SMF->>UPF: (16a) PFCP Session Modification Request [DL FAR に gNB F-TEID]
    UPF-->>SMF: (16b) PFCP Session Modification Response
    Note over UE,UPF: ここからDL Dataも流れる（UPF → gNB → UE）
    SMF-->>AMF: (17) UpdateSMContext Response

ステップの要点¶

AMFのSMF Selection、SMFのUPF Selectionで実際にどの条件をどう重み付けするかは、オペレータ設定・Vendor実装依存 です（静的設定、NRF Discoveryの併用など）。

How — N3 Tunnel の両端はどこで決まるか¶

N3 は gNB ⇔ UPF の GTP-U Tunnel です（TS 23.501 Clause 4.2.3 / TS 29.281 Clause 5、要確認）。Tunnel は 方向ごと に、受信側が自分の F-TEID（IPアドレス + TEID） を相手に教える形で作られます。

CN側Tunnel情報をSMFが割り当てるか、UPFに割り当てさせるかは、どちらも規定上あり得ます（TS 23.501 Clause 5.8.2.3、要確認）。

UL:  UPF ──(F-TEID: 198.51.100.20 / 0x00000101)──► SMF ──N2 SM──► gNB
     gNB は以後、UL GTP-U を 198.51.100.20 / TEID 0x00000101 へ送る

DL:  gNB ──(F-TEID: 192.0.2.10 / 0x12345678)──► AMF ──► SMF ──PFCP──► UPF
     UPF は以後、DL GTP-U を 192.0.2.10 / TEID 0x12345678 へ送る

（アドレスはドキュメント用の例示アドレス、TEIDは架空値です。）

GTP-U ヘッダに載る TEID は 受信側が割り当てた値 です（TS 29.281 Clause 5.1、要確認）。したがって UL の GTP-U には UPF 側の TEID、DL の GTP-U には gNB 側の TEID が載ります。Captureで TEID を見るときは「この値は誰が払い出したものか」を意識します。

UPF の中では — PDR → FAR（最小イメージ）¶

N4 で UPF に入るルールの最小単位は、PDR（Packet Detection Rule） と、それが指す FAR（Forwarding Action Rule） の組です（TS 29.244 Clause 5.2.1、要確認）。

Packet 到着（N3 からの UL GTP-U / N6 からの DL IP Packet）
   │
   ▼
PDR 「このPacketはどのSession・どのTrafficか」
   │   UL: 受信した F-TEID（UPF 側 TEID）等で判定
   │   DL: 宛先の UE IP アドレス等で判定
   ▼
FAR 「どう処理するか」= Apply Action
   ├─ FORW  転送（DL なら Outer Header Creation = gNB F-TEID で GTP-U カプセル化）
   ├─ DROP  破棄
   ├─ BUFF  バッファ
   └─ NOCP  最初のDL Packet到着をCP（SMF）へ通知（BUFF 設定時のみ設定可。TS 29.244 Clause 8.2.26、要確認）

Apply Action は排他的な1値ではなく フラグの組み合わせ で、ほかに DUPL 等もあります（詳細は次章）。

Apply Action は TS 29.244 Clause 8.2.26（要確認）で定義されます。本手続きとの関係で重要なのは、PFCP Session Establishment の時点では DL FAR に入れるべき gNB F-TEID がまだ無い ことです。step 16 の Modification で DL FAR が更新されて初めて、DL が gNB へ転送されます。Establishment 時点の DL FAR をどう作っておくか（BUFF / DROP 等）は SMF実装依存 です。QER / URR を含むルールの詳細は次章 PFCP と PDR / FAR / QER / URR で扱います。

N3 Tunnel を作っている Control Plane は UE・AMF・SMF・gNB・UPF にまたがります。 F-TEIDの受け渡しが失敗すると、失敗した箇所によって、片方向だけ通信できない、または両方向とも通信できない状態になり得ます。

How — N1 / N2 / N3 / N4 の全体像¶

flowchart LR
    UE -- "N1 (NAS)" --> AMF
    gNB -- "N2 (NGAP)" --> AMF
    AMF -- "N11 (Nsmf / Namf)" --> SMF
    SMF -- "N4 (PFCP)" --> UPF
    gNB -- "N3 (GTP-U)" --> UPF
    UPF -- "N6" --> DN[(Data Network)]

Packet Analysis (Wireshark)¶

Display Filter¶

フィールド名はWiresharkの版で異なるため断定しません（要確認）。NASが暗号化されている場合、復号できなければ5GSMの中身は見えません。

時系列で並べる¶

[N1/N2] Uplink NAS Transport
         └─ UL NAS TRANSPORT └─ PDU Session Establishment Request (PSI=1)
[N4]    PFCP Session Establishment Request / Response   ← UPF側 F-TEID（Created PDR）
[N2]    PDU Session Resource Setup Request
         ├─ NAS-PDU └─ DL NAS TRANSPORT └─ PDU Session Establishment Accept
         └─ PDU Session Resource Setup Request Transfer
              └─ UL NG-U UP TNL Information   ← UPF側 F-TEID
[N2]    PDU Session Resource Setup Response
         └─ PDU Session Resource Setup Response Transfer
              └─ DL QoS Flow per TNL Information   ← gNB側 F-TEID
[N4]    PFCP Session Modification Request / Response   ← FAR / Outer Header Creation
[N3]    GTP-U (UL: TEID=UPF側, DL: TEID=gNB側)

N1/N2・N4・N3 の3つのCaptureを 時系列で並べ、F-TEID を突き合わせられる ようになると、PDU Session の解析能力が大きく上がります。

Decode例（概念表現）— N3 の UL GTP-U¶

以下は表示構造の概念表現で、アドレス・TEID・UE IP は架空例です（実キャプチャではありません）。

IP (outer)  Src: 192.0.2.10 (gNB N3)  Dst: 198.51.100.20 (UPF N3)
└─ UDP  Dst Port: 2152
    └─ GTP-U (GTPv1)
        ├─ Message Type: G-PDU (255)
        ├─ TEID: 0x00000101                 ← UPF が払い出した UL 側 TEID
        ├─ Extension Header: PDU Session Container
        │   ├─ PDU Type: UL PDU SESSION INFORMATION
        │   └─ QFI: 1
        └─ T-PDU (inner)
            └─ IP  Src: 10.45.0.2 (UE IP)  Dst: 203.0.113.5

• 外側IPの送信元・宛先は gNB と UPF の N3 アドレス、内側IPの送信元は PDU Session に割り当てられた UE IP です（通常はSMFが割り当てますが、UPFや外部（DN-AAA / DHCP 等）による割り当てもあり得ます。TS 23.501 Clause 5.8.2.2、要確認）。外側と内側を混同しないようにします。
• GTP-U の UDP ポート 2152 は TS 29.281 Clause 4.4.2（要確認）、PDU Session Container 拡張ヘッダ（QFI を運ぶ）は TS 29.281 Clause 5.2.2.7 / TS 38.415 Clause 5.5.2（要確認）で規定されます。
• DL では外側IPの向きが逆になり、TEID は gNB が払い出した値（例: 0x12345678）、PDU Type は DL PDU SESSION INFORMATION になります。

Trouble Shooting¶

闇雲にPacketを見るのではなく、上流から順に確認します。

① UE      PDU Session Establishment Request は出ているか（N1）
② AMF     NAS を受信し、SMF Selection に成功したか
③ SMF     CreateSMContext が成功したか（N11）
④ SMF     UPF Selection に成功したか
⑤ N4      PFCP Session Establishment は成功したか（Cause）
⑥ N2      PDU Session Resource Setup Request が gNB に届いたか
⑦ UE      PDU Session Establishment Accept を受信したか（step 13）
⑧ N2      Setup Response は成功し、gNB の N3 F-TEID が返ってきたか（Failed List / Cause）
⑨ N4      PFCP Session Modification で gNB F-TEID が UPF に反映されたか
⑩ N3      GTP-U が両方向に流れているか

典型事例1: PFCP までは成功、N2 で失敗¶

PDU Session Establishment Request（N1）   OK
CreateSMContext（N11）                    OK
PFCP Session Establishment（N4）          OK   ← UPF 側の準備は完了
PDU Session Resource Setup（N2）          NG   ← ここで止まる

N4 が成功している時点で、UPF は求められた役割を果たしています。失敗しているのは SMF → AMF → gNB の区間なので、「UPFの不具合」を最初に疑うより、次を順に確認する方が合理的です。

1. N2 SM 情報の中身 — QoS Flow のパラメータ（5QI / ARP 等）、S-NSSAI、UL NG-U UP TNL Information（Transport Layer Address = UPF の N3 アドレス）
2. gNB の設定・能力 — その S-NSSAI をサポートしているか、要求された QoS を受け入れられるか、Transport Layer Address の種別（IPv4 / IPv6）を扱えるか（判定ロジックは実装依存）
3. NGAP の結果 — PDU Session Resource Setup Response の Failed to Setup List。Cause は各項目の PDU Session Resource Setup Unsuccessful Transfer（N2 SM 情報の OCTET STRING）の中にあります（TS 38.413 Clause 8.2.1 / Clause 9.3.4 / Clause 9.3.1.2、要確認）

gNB での失敗結果も N2 SM 情報として AMF 経由で SMF へ戻り、SMF は N4 Session の解放などの後処理を行い得ます（詳細な扱いは TS 23.502 Clause 4.3.2.2.1、要確認）。

典型事例2: N2 も Accept も成功したのに Data が流れない¶

NAS（Request / Accept）          OK
N11（CreateSMContext / Update）  OK
N4（Establishment）              OK
N2（Resource Setup）             OK
Data（N3 GTP-U）                 NG

Control Plane が全部成功していても、User Plane が通る保証はありません。Control Plane Success ≠ User Plane Success です。次の層を上から順に確認します。

Capture点を gNB の N3 送出 → UPF の N3 受信 → UPF の N6 送出 と順にずらし、GTP-U / 内側IPが どこまで届いているか を確かめると、失敗区間を素早く絞れます。

F-TEID 比較表を作る¶

この例では DL の TEID が一致していないため、UPF が送る DL GTP-U を gNB は正しいセッションとして受け付けられません。未知のTEIDであれば、gNB はそのG-PDUを破棄し、Error Indication を返すと規定されています（TS 29.281 Clause 7.3.1、要確認）。送出頻度の制限などは実装依存です。

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

特に NAS上でUEが割り当てる PDU Session ID（1〜15） と Vendor内部の Session ID を混同しないようにします。

EPC（4G）との比較¶

3GPP Specification¶

区間ごとに、まず開く仕様は次のとおりです。

手続き全体（誰が・いつ・何を）  → TS 23.502 Clause 4.3.2.2.1（概念・機能は TS 23.501）
UE ⇔ SMF の 5GSM（N1）          → TS 24.501 Clause 6.4.1 / Clause 8.3
AMF ⇔ SMF の SBI（N11）         → TS 29.502 Clause 5.2.2（Nsmf）/ TS 29.518 Clause 5.2.2（Namf）（要確認）
AMF ⇔ gNB の NGAP（N2）         → TS 38.413 Clause 8.2.1 / Clause 9.3.4（要確認）
SMF ⇔ UPF の PFCP（N4）         → TS 29.244 Clause 7.5
gNB ⇔ UPF の GTP-U（N3）        → TS 29.281 Clause 5 / TS 38.415 Clause 5.5.2（要確認）

Summary¶

• PDU Session は UE と DN の間で PDU Connectivity Service を提供する関連付け（TS 23.501 Clause 3.1、要確認）。経路は UE ─ gNB ─N3─ UPF ─N6─ DN
• Registration ≠ PDU Session Establishment。登録済みでもPDU Sessionが無ければUser Planeは無い
• PDU Session は NAS上でUEが割り当てる PDU Session ID（1〜15） で識別され、DNN + S-NSSAI で「どのSliceで、どのDNへ」が決まる
• 5GSMメッセージは UL/DL NAS TRANSPORT に包まれ、AMFが N1 SM container として中身を処理せずSMFと中継する
• N1 SM = SMF ⇔ UE 用、N2 SM = SMF ⇔ RAN 用。どちらもAMFが運ぶ
• SMFは PFCP Establishment（UL側を作る）→ Modification（gNBのF-TEIDをDL FARへ反映） の2段構えでUPFを設定する
• Accept はUEへ PFCP Modification の 前に 届き得る。Control Plane Success ≠ User Plane Success
• GTP-U の TEID は 受信側が払い出した値。UL には UPF 側、DL には gNB 側の TEID が載る
• 「N4 成功・N2 失敗」はまず N2 SM 情報と gNB 設定、「CP 全成功・Data 不通」は F-TEID・N3 到達性・PDR/FAR・N6 戻り経路 を疑う
• Traceでは N1/N2・N4・N3 を時系列で並べ、F-TEID を突き合わせる

理解度チェック¶

Next Step¶

• UPFに入ったルールの中身 → PFCP と PDR / FAR / QER / URR
• 既存PDU SessionのN3再確立（前章） → CM-IDLE / CM-CONNECTED と Service Request
• 手続き全体の基本 → PDU Session Establishment / PDU Session Modification / Release
• CM-IDLEからのN3再確立 → Service Request
• QoS Flow / 5QI → QoS
• メッセージ・IE → NAS辞典 / NGAP辞典 / PFCP辞典