title: PDU Session Establishment Deep Dive — How N1 SM / N2 SM / N3 / N4 Work Together to Build the User Plane description: A deep dive into UE-requested PDU Session Establishment from four perspectives: N1 SM (toward the UE), N2 SM (toward the RAN), N4 (PFCP), and N3 (GTP-U). Explains PDU Session ID / DNN / S-NSSAI, relay via UL NAS Transport and Namf/Nsmf, SMF and UPF selection, the two-stage PFCP Session Establishment and Modification, TEID exchange, and troubleshooting through timeline correlation in Wireshark, with 3GPP clause references. keywords: - PDU Session Establishment - N1 SM - N2 SM Information - PDU Session Resource Setup - Nsmf_PDUSession_CreateSMContext - Namf_Communication_N1N2MessageTransfer - PFCP Session Establishment - PFCP Session Modification - TEID - F-TEID - SMF Selection - UPF Selection - 5GC tags: - Level ∞ - Session Management - NAS - NGAP - PFCP category: Deep Dive

PDU Session Establishment Deep Dive — How N1 SM / N2 SM / N3 / N4 Work Together to Build the User Plane¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that Registration and PDU Session Establishment are separate procedures
• Explain the difference between N1 SM information (toward the UE) and N2 SM information (toward the RAN), and why the AMF relays both
• Explain why the SMF configures the UPF in two stages, PFCP Session Establishment → Modification (the gNB-side TEID becomes known later)
• Trace who sends the UL-side (UPF F-TEID) and DL-side (gNB F-TEID) ends of the N3 Tunnel to whom, in which messages
• When a PDU Session cannot be established or Data does not flow despite successful establishment, troubleshoot in the order N1 → N11 → N4 → N2 → N4 → N3

Prerequisites¶

• PDU Session Establishment — basics of the overall procedure (this chapter digs into the "wiring")
• Service Request — re-establishing N2/N3 from CM-IDLE. The flow of N2 SM information is shared with this chapter
• Supplementary: N1 / N2 / N3 / N4 / N11

Why — Why can't the UE communicate even after Registration succeeds?¶

Registration is the procedure for "registering the UE with 5GS," while PDU Session Establishment is the procedure for "creating a logical session for the UE to communicate with a Data Network (DN)." They are separate procedures (TS 23.501 §5.6.1).

Registration succeeds
   → UE is registered with the 5GC (5GMM-REGISTERED)
   → But without a PDU Session, there is no User Plane
   → Internet communication is not yet possible

Analogy: Registration is "getting a building access badge," while a PDU Session is "arranging a dedicated elevator to the destination floor (DN)." Even with an access badge, you cannot reach your destination without the elevator.

What — Three values that identify a PDU Session¶

PDU Session ID¶

Each PDU Session is identified within the UE by a PDU Session ID. One UE can have multiple PDU Sessions at the same time.

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)¶

Indicates which Data Network the UE wants to connect to. It is conceptually equivalent to the APN in 4G EPC (definition: TS 23.501 §3.1; format: TS 23.003 §9A, to be confirmed).

DNN = internet    → Internet
DNN = ims         → IMS (e.g. VoNR)
DNN = enterprise  → Enterprise network

S-NSSAI¶

Indicates which Network Slice to use for the connection (SST + optional SD. TS 23.003 §28.4.2, to be confirmed).

S-NSSAI (SST = 1, SD = 010203)  +  DNN = internet
              ↓
"Which Slice, and which DN"
              ↓
Input to SMF Selection / UPF Selection

If the UE omits DNN / S-NSSAI in the Request, the network may use the default values in subscription data (default DNN / default S-NSSAI) (TS 23.502 §4.3.2.2.1, to be confirmed).

What — Who does what?¶

The AMF is the controller for Mobility / Access, the SMF is the controller for PDU Sessions, and the UPF is the entity that carries User Packets (TS 23.501 §6.2.1 / §6.2.2 / §6.2.3).

What — N1 SM information and N2 SM information¶

5GSM messages are carried inside 5GMM messages¶

PDU SESSION ESTABLISHMENT REQUEST is a 5GSM (5G Session Management) message. Since there is no direct NAS connection between the UE and SMF, the UE puts it in the Payload container of 5GMM UL NAS TRANSPORT and sends it to the 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 (optional)
        └─ Payload container
            └─ PDU SESSION ESTABLISHMENT REQUEST (5GSM)
                ├─ PDU session ID = 1
                ├─ PTI
                └─ PDU session type, etc.

The AMF looks at the outer (UL NAS TRANSPORT) PDU session ID, S-NSSAI, and DNN to select the SMF, then passes the inner 5GSM message as-is to the SMF as an N1 SM container (TS 23.502 §4.3.2.2.1).

Organized by direction¶

UE  ──N1──►  AMF  ──N11──►  SMF        N1 SM (toward the UE)
gNB ◄──N2──  AMF  ◄──N11──  SMF        N2 SM (toward the RAN)

Remember: N1 SM = for SMF ⇔ UE; N2 SM = for SMF ⇔ RAN; the AMF carries both. The SMF never sends NGAP directly to the gNB.

How — End-to-End Call Flow¶

The following simplifies the main parts of TS 23.502 §4.3.2.2.1 (UE-requested PDU Session Establishment, non-roaming / Local Breakout). Steps for UDM and PCF interaction, secondary authentication, Charging, etc. are omitted (step numbering varies by release, so to be confirmed).

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, etc.; NRF may also be involved)
    AMF->>SMF: (3) Nsmf_PDUSession_CreateSMContext Request [N1 SM container]
    Note over SMF: (4) UDM interaction (omitted)
    SMF-->>AMF: (5) CreateSMContext Response
    Note over SMF: PCF interaction / secondary authentication (omitted) / (8) UPF Selection / UE IP address assignment
    SMF->>UPF: (10a) PFCP Session Establishment Request [Create PDR/FAR/QER/URR]
    UPF-->>SMF: (10b) PFCP Session Establishment Response [UPF-side F-TEID, etc.]
    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 information]
    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; position in diagram after step 14, to be confirmed)
    AMF->>SMF: (15) Nsmf_PDUSession_UpdateSMContext Request [N2 SM information]
    SMF->>UPF: (16a) PFCP Session Modification Request [gNB F-TEID in DL FAR]
    UPF-->>SMF: (16b) PFCP Session Modification Response
    Note over UE,UPF: DL Data also flows from this point (UPF → gNB → UE)
    SMF-->>AMF: (17) UpdateSMContext Response

Key points by step¶

The specific criteria and weighting used in AMF SMF Selection and SMF UPF Selection are operator-configuration and vendor-implementation dependent (e.g. static configuration, or use of NRF Discovery).

How — Where are the two ends of the N3 Tunnel determined?¶

N3 is a GTP-U Tunnel between the gNB and UPF (TS 23.501 §4.2.3 / TS 29.281 §5, to be confirmed). A Tunnel is created per direction by the receiving side telling the other side its F-TEID (IP address + TEID).

The CN-side Tunnel information may be allocated by the SMF or by the UPF; both are allowed by the specifications (TS 23.501 §5.8.2.3, to be confirmed).

UL:  UPF ──(F-TEID: 198.51.100.20 / 0x00000101)──► SMF ──N2 SM──► gNB
     From then on, the gNB sends UL GTP-U to 198.51.100.20 / TEID 0x00000101

DL:  gNB ──(F-TEID: 192.0.2.10 / 0x12345678)──► AMF ──► SMF ──PFCP──► UPF
     From then on, the UPF sends DL GTP-U to 192.0.2.10 / TEID 0x12345678

(The addresses are documentation example addresses; the TEIDs are fictitious values.)

The Control Plane creating the N3 Tunnel spans the UE, AMF, SMF, gNB, and UPF. If F-TEID exchange fails, the result may be one-way or no communication, depending on where it fails.

How — Overall picture of 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¶

Field names vary by Wireshark version and are not asserted here (to be confirmed). If NAS is encrypted, the 5GSM contents are not visible unless it can be deciphered.

Arrange by timeline¶

[N1/N2] Uplink NAS Transport
         └─ UL NAS TRANSPORT └─ PDU Session Establishment Request (PSI=1)
[N4]    PFCP Session Establishment Request / Response   ← UPF-side 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-side F-TEID
[N2]    PDU Session Resource Setup Response
         └─ PDU Session Resource Setup Response Transfer
              └─ DL QoS Flow per TNL Information   ← gNB-side F-TEID
[N4]    PFCP Session Modification Request / Response   ← FAR / Outer Header Creation
[N3]    GTP-U (UL: UPF-side TEID, DL: gNB-side TEID)

Your PDU Session analysis improves significantly once you can put N1/N2, N4, and N3 captures in time order and correlate their F-TEIDs.

Trouble Shooting¶

Rather than looking at packets at random, check from upstream in order.

① UE      Is PDU Session Establishment Request present? (N1)
② AMF     Was NAS received, and did SMF Selection succeed?
③ SMF     Did CreateSMContext succeed? (N11)
④ SMF     Did UPF Selection succeed?
⑤ N4      Did PFCP Session Establishment succeed? (Cause)
⑥ N2      Did PDU Session Resource Setup Request reach the gNB?
⑦ UE      Did the UE receive PDU Session Establishment Accept? (step 13)
⑧ N2      Did Setup Response succeed, and was the gNB's N3 F-TEID returned? (Failed List / Cause)
⑨ N4      Was the gNB F-TEID applied to the UPF by PFCP Session Modification?
⑩ N3      Is GTP-U flowing in both directions?

Build an F-TEID comparison table¶

In this example, the DL TEID does not match, so the gNB cannot accept the DL GTP-U sent by the UPF as the correct session. The specifications state that for an unknown TEID, the gNB discards the G-PDU and returns an Error Indication (TS 29.281 §7.3.1, to be confirmed). Limits on the transmission frequency, etc. are implementation-dependent.

Boundary between 3GPP specifications and vendor implementations¶

In particular, do not confuse the PDU Session ID (1–15) allocated by the UE in NAS with a vendor-internal Session ID.

Comparison with EPC (4G)¶

3GPP Specification¶

Summary¶

• Registration ≠ PDU Session Establishment. Even when registered, there is no User Plane without a PDU Session
• A PDU Session is identified by the PDU Session ID (1–15) allocated by the UE in NAS, while DNN + S-NSSAI determine "which Slice and which DN"
• 5GSM messages are carried inside UL/DL NAS TRANSPORT, and the AMF relays them to and from the SMF as an N1 SM container, without processing their contents
• N1 SM = for SMF ⇔ UE; N2 SM = for SMF ⇔ RAN. The AMF carries both
• The SMF configures the UPF in two stages: PFCP Establishment (create the UL side) → Modification (apply the gNB F-TEID to the DL FAR)
• Accept may reach the UE before PFCP Modification. Control Plane Success ≠ User Plane Success
• In traces, put N1/N2, N4, and N3 in time order and correlate the F-TEIDs

Comprehension check¶

Next Step¶

• Contents of the rules installed in the UPF → PFCP and PDR / FAR / QER / URR
• Basics of the overall procedure → PDU Session Establishment / PDU Session Modification / Release
• Re-establishing N3 from CM-IDLE → Service Request
• QoS Flow / 5QI → QoS
• Messages and IEs → NAS Dictionary / NGAP Dictionary / PFCP Dictionary