N3 — (R)AN ⇔ UPF (GTP-U Reference Point)¶
Learning objectives¶
After reading this page, you will be able to:
- Explain that N3 is the user-plane interface connecting the base station (gNB) and the UPF.
- State N3's protocol (GTP-U) and its lower transport (UDP/IP).
- Distinguish the roles by which TEID identifies the GTP-U tunnel and QFI identifies the QoS Flow.
- Explain that N3 is a data path separated from the control plane (N2).
- Explain how it corresponds to 4G (EPC) S1-U (GTP-U).
Prerequisites¶
It will go more smoothly if you understand the following first.
- The positioning of GTP-U and UDP/IP → Protocol dictionary
- The core-side NF that terminates N3 → UPF
- The paired control plane → N2
- The procedure in which the tunnel over N3 is established → PDU Session establishment
- The concept of an interface → Interface dictionary
Why — why it is needed¶
Even after control messages (N2) agree that "this UE has been registered" and "a session has been set up," the actual user data (web pages, video, voice packets) has not yet flowed a single byte. What the user really uses is the fat pipe that carries that real data at high speed.
Moreover, a single base station (gNB) has many UEs hanging off it, and a single UPF accommodates many gNBs. Amid the enormous number of packets mixing and flowing, a mechanism is needed to reliably tell "which UE's, which flow's packet is this?" This "road that, separate from control, carries real user data in a tunnel and identifies flows" is N3. Without N3, even if a session is set up, there is no path to carry the real data.
To use an analogy: if N2 is the control-tower radio communication that decides "who gets through and how," then N3 is the dedicated lane of the highway on which cars actually drive. Even if control clearance is granted, you cannot move without the road itself to drive on.
Overview¶
N3 is the user-plane interface connecting (R)AN(gNB) ⇔ UPF. The protocol flowing on top is GTP-U (GPRS Tunneling Protocol - User plane), and below it is UDP over IP.
N3 carries user data encapsulated in a GTP-U tunnel. There are two keys for identification.
| Identifier | What it identifies | Where it is carried |
|---|---|---|
| TEID (Tunnel Endpoint ID) | The GTP-U tunnel (≈ which endpoint to deliver to) | GTP-U basic header |
| QFI (QoS Flow Identifier) | The QoS Flow within the session (flows of differing priority) | GTP-U extension header (PDU Session Container, TS 38.415) |
The control/user separation — control signaling on N2, user data on N3 — is upheld here too.
Basic Concept — a beginner-friendly explanation¶
Let us liken N3 to a parcel delivery service that carries packages. In the Why section we used the highway analogy, but focusing on individual packets, the parcel envelope is easier to grasp.
Rather than flowing the data the UE wants to send (the original IP packet) bare, it is wrapped in an envelope (GTP-U) and carried.
- The envelope (GTP-U tunnel) = the outer wrapping that encloses the original packet whole. The contents (the user's IP packet) stay as they are.
- The destination label (TEID) = the number stuck on the front of the envelope. The UPF and the gNB look at this label to decide "which tunnel's parcel is this = where to deliver it."
- The priority sticker (QFI) = the "express" / "regular" distinction stuck on the envelope. Even within the same session, it indicates QoS differences such as prioritizing video and deferring background updates.
And the road has two directions, uplink and downlink. UE→gNB→UPF→Internet is uplink, and the reverse is downlink. Labels (TEIDs) are assigned separately for uplink and downlink, and the gNB-side endpoint and the UPF-side endpoint each have their own TEID. Because TEID is a scheme where each endpoint tells the other "the number to use when I receive," the numbers differ for uplink and downlink.
Protocol / Transport¶
| Item | Content |
|---|---|
| Protocol | GTP-U (GPRS Tunneling Protocol - User plane) — TS 29.281 |
| Lower Transport | UDP over IP |
| Port | UDP 2152 (the well-known port for GTP-U; common to 4G/5G) |
| Characteristics | Tunnel identification by TEID. Encapsulates the user's IP packet as a T-PDU (= the original user IP packet that gets encapsulated) |
| QoS carriage | The QFI is carried in the PDU Session Container of the GTP-U extension header (TS 38.415) |
GTP-U is the 'U-plane version' of GTP
GTP (GPRS Tunneling Protocol) has GTP-C for control and GTP-U for user data. What N3 uses is GTP-U (TS 29.281), devoted to being a real-data pipe. Because 5GC control is handled not by GTP-C but by N2 (NGAP) and SBA, only GTP-U is used on N3.
Architecture¶
This shows how N3 connects the gNB and the UPF, carrying user data over a path separate from the control plane (N2).
flowchart LR
UE(("UE"))
gNB["gNB (base station)"]
AMF["AMF"]
UPF["UPF"]
UPF2["UPF (anchor)"]
DN["DN (data network)"]
UE -- "radio" --> gNB
gNB == "N3 (GTP-U / UDP:2152)" ==> UPF
UPF -- "N9 (GTP-U)" --> UPF2
UPF2 -- "N6" --> DN
gNB -. "N2 (NGAP) control on a separate line" .-> AMF
classDef uplane fill:#eef,stroke:#66f,stroke-width:2px;
classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
class gNB,UPF,UPF2 uplane;
class AMF ctrl;
How to read the diagram: the thick line (==>) is N3's user-data path (the GTP-U tunnel). Note the control/user separation, where the dotted-line N2 control flows on a completely separate line. When the UPF is in multiple stages, the UPFs are connected by N9 (also GTP-U).
Procedures that use it¶
The N3 tunnel is established as the U-Plane (user plane) within PDU Session establishment.
- U-Plane establishment: as part of PDU Session establishment, the gNB and the UPF exchange the TEIDs and transport addresses (IPs) each uses at its endpoint. This creates two N3 GTP-U tunnels, uplink and downlink (the TEID exchange itself is done by control such as N2/N4).
- Handover: when the UE moves to a different gNB, the endpoint of the downlink tunnel as seen from the UPF side (the gNB's TEID/address) switches, and the N3 path is re-pointed to the new gNB.
To avoid duplication, see PDU Session establishment for the detailed procedure flow. Here it is enough to grasp the positioning of "N3 = the fat pipe of user data established for that session."
Main Messages¶
Because GTP-U is a protocol devoted to being a pipe, its control messages are few. Most are G-PDUs that carry real data.
| Message | Purpose |
|---|---|
| G-PDU | The true lead role: encapsulates and carries the user's IP packet (T-PDU) |
| Echo Request / Response | Connectivity check with the peer endpoint (liveness check of the path) |
| Error Indication | Notification of an error, e.g., a packet was received for an unknown TEID |
| End Marker | A marker indicating the last packet on the old path at a path switch (handover, etc.) |
For details of each message, see the Message dictionary.
Packet Analysis (Wireshark)¶
N3 is observed as GTP-U, with UDP below it.
| Purpose | Display Filter |
|---|---|
| Extract GTP-U messages | gtp |
| Narrow by the N3 port | udp.port == 2152 |
| Follow a specific tunnel | gtp.teid == 0x... (narrow by TEID) |
Decode highlights:
- The TEID in the GTP-U header lets you identify which tunnel (≈ which UE's which session) it is. Note that the TEID differs for uplink and downlink.
- The QFI carried in the extension header (PDU Session Container, TS 38.415) tells you which QoS Flow the packet belongs to.
- In a G-PDU, the user's IP packet nested inside the GTP-U header is further decoded. This two-layer structure — "the user IP nested inside GTP-U" — is key to understanding N3 (analogous to NAS being nested inside NGAP on N2).
Comparison with EPC¶
- In 4G: GTP-U (TS 29.281) flowed over S1-U, connecting the base station (eNB) and the SGW, and over S5/S8 between SGW⇔PGW. The point of identifying user-data tunnels by TEID is the same.
- In 5G: GTP-U (TS 29.281, the same protocol) flows over N3, connecting the gNB and the UPF, and over N9 between UPFs. QoS identification became QFI-based, and the point that it is carried in the GTP-U extension header (PDU Session Container) was added.
| 4G (EPC) | 5G (5GC) |
|---|---|
| S1-U (eNB ⇔ SGW) | N3 (gNB ⇔ UPF) |
| S5/S8 (SGW ⇔ PGW) | N9 (UPF ⇔ UPF) |
| GTP-U (TS 29.281) | GTP-U (TS 29.281, common) |
| QoS per EPS Bearer | Per QoS Flow, QFI carried in the GTP-U extension header |
GTP-U continues from 4G and was extended in 5G
GTP-U itself is a mature protocol inherited from 4G. The main change in 5G is that the QoS model changed from Bearer-based to QoS Flow-based, and the QFI came to be carried in the GTP-U extension header.
3GPP Specification¶
- 3GPP TS 29.281 — GTP-U (GPRS Tunneling Protocol - User plane). Individual clause numbers are to be confirmed
- 3GPP TS 38.415 — PDU Session User Plane Protocol (QFI carriage via the PDU Session Container). Individual clause numbers are to be confirmed
- 3GPP TS 23.501 §4 — System architecture and reference points (definition of N3)
Summary¶
- N3 is the user-plane interface connecting (R)AN(gNB) ⇔ UPF, and its protocol is GTP-U.
- The lower transport is UDP over IP, and the port is 2152.
- TEID identifies the GTP-U tunnel and QFI identifies the QoS Flow (the QFI is carried in the GTP-U extension header / PDU Session Container, TS 38.415).
- The control/user separation — control on N2, data on N3 — is upheld. Between UPFs is N9 (also GTP-U).
- It corresponds to 4G's S1-U (GTP-U, TS 29.281), and in 5G the QFI extension was added to the same GTP-U.
Next Step¶
- UPF — the core-side NF that terminates N3
- N2 — the control plane paired with N3 (NGAP/SCTP)
- PDU Session establishment — the procedure in which N3's U-Plane tunnel is established
- Interface dictionary — to check reference points not yet documented, such as N9
- Message dictionary — to check GTP-U messages