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")
• CM-IDLE / CM-CONNECTED and Service Request — the previous chapter. It covers re-establishing N2/N3 of an existing PDU Session with Service Request. This chapter takes a step back and covers how that N3 is created in the first place
• 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?¶

A PDU Session is defined as "an association between the UE and a Data Network (DN) that provides a PDU Connectivity Service" (TS 23.501 Clause 3.1, to be confirmed). Viewed as a User Plane path, it looks like this:

UE ──(radio)── gNB ──N3 (GTP-U)── UPF ──N6── DN (Internet / IMS / enterprise network)

PDU Session Establishment creates the logical session that makes this path work.

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 Clause 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 Clause 3.1; format: TS 23.003 Clause 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 Clause 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 Clause 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 Clause 6.2.1 / Clause 6.2.2 / Clause 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 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 (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 Clause 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 Clause 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.#59; 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#59; 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 Clause 4.2.3 / TS 29.281 Clause 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 Clause 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 TEID carried in the GTP-U header is the value allocated by the receiving side (TS 29.281 Clause 5.1, to be confirmed). Therefore UL GTP-U carries the UPF-side TEID, and DL GTP-U carries the gNB-side TEID. When looking at a TEID in a capture, keep in mind "who allocated this value."

Inside the UPF — PDR → FAR (minimal picture)¶

The minimal unit of the rules installed in the UPF over N4 is a pair of a PDR (Packet Detection Rule) and the FAR (Forwarding Action Rule) it points to (TS 29.244 Clause 5.2.1, to be confirmed).

Packet arrives (UL GTP-U from N3 / DL IP Packet from N6)
   │
   ▼
PDR  "Which Session and which Traffic does this Packet belong to?"
   │   UL: matched by the received F-TEID (UPF-side TEID), etc.
   │   DL: matched by the destination UE IP address, etc.
   ▼
FAR  "How should it be handled?" = Apply Action
   ├─ FORW  Forward (for DL, GTP-U encapsulation with Outer Header Creation = gNB F-TEID)
   ├─ DROP  Discard
   ├─ BUFF  Buffer
   └─ NOCP  Notify the CP (SMF) of the first DL Packet arrival (only when BUFF is set; TS 29.244 Clause 8.2.26, to be confirmed)

Apply Action is not a single exclusive value but a combination of flags, and there are others such as DUPL (details in the next chapter).

Apply Action is defined in TS 29.244 Clause 8.2.26 (to be confirmed). What matters for this procedure is that at the time of PFCP Session Establishment, the gNB F-TEID to put in the DL FAR does not exist yet. DL is forwarded to the gNB only after the DL FAR is updated by the Modification in step 16. How the DL FAR is configured at Establishment time (BUFF / DROP, etc.) is SMF-implementation-dependent. Details of the rules, including QER / URR, are covered in the next chapter, PFCP and PDR / FAR / QER / URR.

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.

Decode example (conceptual) — UL GTP-U on N3¶

The following is a conceptual representation of the display structure; the addresses, TEID, and UE IP are fictitious examples (not an actual capture).

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                 ← UL-side TEID allocated by the UPF
        ├─ 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

• The outer IP source and destination are the N3 addresses of the gNB and UPF; the inner IP source is the UE IP assigned to the PDU Session (usually assigned by the SMF, but assignment by the UPF or externally (DN-AAA / DHCP, etc.) is also possible; TS 23.501 Clause 5.8.2.2, to be confirmed). Do not confuse the outer and inner headers.
• The GTP-U UDP port 2152 is specified in TS 29.281 Clause 4.4.2 (to be confirmed), and the PDU Session Container extension header (carrying the QFI) in TS 29.281 Clause 5.2.2.7 / TS 38.415 Clause 5.5.2 (to be confirmed).
• In DL, the outer IP direction is reversed, the TEID is the value allocated by the gNB (e.g. 0x12345678), and the PDU Type is DL PDU SESSION INFORMATION.

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?

Typical case 1: Successful up to PFCP, fails on N2¶

PDU Session Establishment Request (N1)   OK
CreateSMContext (N11)                    OK
PFCP Session Establishment (N4)          OK   ← the UPF side is ready
PDU Session Resource Setup (N2)          NG   ← stops here

Once N4 has succeeded, the UPF has done what was asked of it. The failure is in the SMF → AMF → gNB segment, so rather than suspecting "a UPF bug" first, it is more rational to check the following in order.

1. Contents of N2 SM information — QoS Flow parameters (5QI / ARP, etc.), S-NSSAI, UL NG-U UP TNL Information (Transport Layer Address = the UPF's N3 address)
2. gNB configuration and capabilities — whether it supports that S-NSSAI, whether it can accept the requested QoS, whether it can handle the Transport Layer Address type (IPv4 / IPv6) (the decision logic is implementation-dependent)
3. NGAP result — the Failed to Setup List in PDU Session Resource Setup Response. The Cause is inside each item's PDU Session Resource Setup Unsuccessful Transfer (an OCTET STRING of N2 SM information) (TS 38.413 Clause 8.2.1 / Clause 9.3.4 / Clause 9.3.1.2, to be confirmed)

The failure result at the gNB is also returned to the SMF via the AMF as N2 SM information, and the SMF may perform follow-up actions such as releasing the N4 Session (detailed handling in TS 23.502 Clause 4.3.2.2.1, to be confirmed).

Typical case 2: N2 and Accept succeed, but Data does not flow¶

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

Even if the entire Control Plane succeeds, there is no guarantee that the User Plane works. Control Plane Success ≠ User Plane Success. Check the following layers from the top.

Moving the capture point in order — gNB N3 egress → UPF N3 ingress → UPF N6 egress — to confirm how far the GTP-U / inner IP gets quickly narrows down the failing segment.

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

For each segment, the specification to open first is:

Overall procedure (who, when, what)  → TS 23.502 Clause 4.3.2.2.1 (concepts / functions in 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) (to be confirmed)
AMF ⇔ gNB NGAP (N2)                  → TS 38.413 Clause 8.2.1 / Clause 9.3.4 (to be confirmed)
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 (to be confirmed)

Summary¶

• A PDU Session is an association between the UE and a DN that provides a PDU Connectivity Service (TS 23.501 Clause 3.1, to be confirmed). The path is UE ─ gNB ─N3─ UPF ─N6─ DN
• 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
• The GTP-U TEID is the value allocated by the receiving side. UL carries the UPF-side TEID; DL carries the gNB-side TEID
• For "N4 succeeds, N2 fails," first suspect N2 SM information and gNB configuration; for "all CP succeeds, no Data," suspect F-TEIDs, N3 reachability, PDR/FAR, and the N6 return route
• 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
• Re-establishing N3 of an existing PDU Session (previous chapter) → CM-IDLE / CM-CONNECTED and Service Request
• 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