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 — 手続き全体の基本（本章はその「配線」部分を深掘りします）
• Service Request — CM-IDLEからN2/N3を再確立する手続き。N2 SM 情報の流れは本章と共通です
• 補助: N1 / N2 / N3 / N4 / N11

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

Registration は「UEを5GSへ登録する」手続き、PDU Session Establishment は「UEがData Network（DN）と通信するための論理セッションを作る」手続きです。両者は別物です（TS 23.501 §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 §3.1、形式は TS 23.003 §9A、要確認）。

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

S-NSSAI¶

どのNetwork Sliceで 接続するかを示します（SST + 任意のSD。TS 23.003 §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 §4.3.2.2.1、要確認）。

What — 誰が何をするのか¶

AMFは Mobility / Access側の司令塔、SMFは PDU Session の司令塔、UPFは User Packetを運ぶ実体 です（TS 23.501 §6.2.1 / §6.2.2 / §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 §8.2.10 / §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 §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 §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 §4.2.3 / TS 29.281 §5、要確認）。Tunnel は 方向ごと に、受信側が自分の F-TEID（IPアドレス + TEID） を相手に教える形で作られます。

CN側Tunnel情報をSMFが割り当てるか、UPFに割り当てさせるかは、どちらも規定上あり得ます（TS 23.501 §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は架空値です。）

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 の解析能力が大きく上がります。

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 が両方向に流れているか

F-TEID 比較表を作る¶

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

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

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

EPC（4G）との比較¶

3GPP Specification¶

Summary¶

• 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
• Traceでは N1/N2・N4・N3 を時系列で並べ、F-TEID を突き合わせる

理解度チェック¶

Next Step¶

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