Where does End-to-End QoS actually materialize?

Beyond abstract 5QI definitions and policy rules in the Core, QoS becomes real only when data flows through the entire network stack — from Application servers through the Core and down to RAN schedulers, where packets are finally transmitted over the air.

This post walks through each stage to reveal how 5G turns high-level QoS rules into concrete packet behavior across the network.

e2e_data_transmissionMulti-flow E2E Data Transmission in 5G Downlink. Three application flows (Video, Audio, Chat) traverse the network stack independently, each mapped to distinct QoS Flows (QFI) at the UPF, then to separate DRBs at the RAN, where MAC scheduling finally allocates radio resources according to 5QI-based priorities.

StepNetwork DomainTransmission UnitControl Mechanism
① Application ServerApp domainApp dataTCP/UDP
② Internet BackbonePublic / MNO ASIP packethop-by-hop routing
③ UPF ingress (Core entry)Core domainIP packetPDR/FAR/QER matching
④ UPF egressCore → RANGTP-U encapsulated packetHTB / DRR / WFQ scheduling
⑤ RAN (gNB)Access domainMAC/RLC PDUPF / RR / RL-based
⑥ UEDevice domainApp dataTCP/UDP delivery

1️⃣ Application Traffic Generation

A single application server generates and delivers multiple types of traffic for service delivery.

For example, in a video conferencing application such as Zoom or Google Meet:

FunctionTransport TypeProtocol / Port ExampleQoS Characteristics
Video streamUDP RTPport 5004high throughput, low delay
Audio streamUDP RTPport 5006low delay, small packet
Chat messageTCPport 443 (WebSocket)best effort
Screen sharingUDP/TCPports 3478–3480 (STUN/TURN)moderate bitrate
Control signalingTCPport 443infrequent

Depending on transport type and QoS characteristics, multiple traffic types are sent, and each of them forms one Transport Flow ➔ IP Flow.

Congestion Control in Transport Layer

Transport Congestion Control (CC) determines how fast the application injects data into the network. The sending rate and pacing behavior directly influence latency, jitter, and loss observed along the path.

⚙️ Common Algorithms

2️⃣ Internet Routing

Global Routing Table (MNO Backbone)

3️⃣ UPF Forwarding in Core Networks

Once IP flows reach the UPF, packets go through the following steps before being forwarded to the target gNB:

  1. The UPF identifies the PDU Session based on the packet’s UE IP address.
  2. According to the PDR (Packet Detection Rule) configured by the SMF, the UPF determines which QoS Flow (QFI) the packet belongs to.
    • The QFI is derived from QoS parameters such as 5QI, GBR, and ARP.
  3. The UPF encapsulates the packet with a GTP-U header containing the QFI and TEID (Tunnel Endpoint ID) (as defined in 3GPP TS 29.281 §5.3)
  4. The UPF forwards the GTP-U encapsulated packet to the RAN (target gNB) via the N3 interface.

UPF Routing Table

TypeOwnerMain FunctionExample
① Global Routing Table (MNO Backbone)MNO Core Router / Aggregation RouterDetermines which UPF to forward incoming Internet packets to“10.10.0.0/16 → UPF_MUC_01”
② Local Routing Table (UPF Entity)Inside UPF server / VM / containerForwards packets either to RAN (gNB) or external network (N6)“RAN subnet → dev n3”, “0.0.0.0/0 → dev n6”

UPF Functional Pipeline

StageProcessing TaskResponsible Entity
Ingress (N6)Match incoming IP packets with PDR / FAR rulesUPF Core
Routing lookupDetermine which RAN tunnel (N3) corresponds to the UE IPUPF local route table
QoS handlingApply HTB / DRR scheduling per QFIUPF scheduler
EncapsulationAdd GTP-U header (TEID, RAN endpoint)UPF
Egress (N3)Forward packet to gNBUPF via local routing interface

*️⃣ IP Flow ⇔ QoS Flow Mapping

The mapping between an IP flow and its corresponding QoS Flow (QFI) is pre-defined by SMF policies. The UPF then determines which QFI each incoming IP packet belongs to.

5G QoS Hierarchy

LevelEntityUnitDescription
QoS Policy LevelPCF (Policy Control Function)5QIDefines service class (delay, reliability, etc.)
Session / Flow ManagementSMF (Session Management Function)QFIDetermines which flow belongs to which QoS Flow (QFI)
Bearer Mapping / EnforcementUPF + RAN (SDAP, scheduler)QFI → DRBExecutes traffic handling (queueing, transmission)

QoS Flow — The Smallest QoS Unit Defined in the 5G Core

A QoS Flow is the finest-grained QoS entity defined by the 5G Core. Each flow is associated with a unique QFI (QoS Flow Identifier) and a set of 5QI-based QoS parameters such as PDB, PER, and GFBR.

PCF — “QoS Class Designer”

📘 PCF = Policy engine that defines and provides QoS policies

➡️ Serves as a context-aware policy engine, not a static table

SMF — “Flow-to-QoS Flow Mapper”

📘 SMF = The manager that constructs actual QoS mappings

Example👇

Flow5QIQFIDescription
UDP:5004 (video)85Streaming QoS Flow
TCP:443 (web)96Best-effort QoS Flow
UDP:5012 (voice)77Conversational QoS Flow

➡️ The SMF acts as a central distributor, deploying QoS policies at the session level.

UPF — “QoS Flow Enforcer”

📘 UPF = The executor that applies QoS in the data plane

➡️ The UPF functions as a QoS enforcement engine, performing queueing, rate control, and forwarding per QoS Flow.

gNB SDAP Layer

📘 SDAP = The orchestrator that binds QoS Flows to radio bearers

SDAP responsibilities

1️⃣ Map QoS Flows (QFIs) to DRBs
2️⃣ Propagate QoS properties (delay, reliability, priority) to lower layers

QoS reflection by layer

➡️ SDAP serves as a control gateway linking QoS Flows to the full radio bearer stack (PDCP–RLC–MAC) for real QoS execution.

*️⃣ PDU Session

A PDU Session is a logical IP session established between the UE and the Core Network. Each session represents a GTP-U tunnel (UE ↔ UPF) defined by the following configuration set.

PDU Session Configuration

➡️ All QoS Flows following this configuration belong to and are managed under the same PDU Session.

UE ↔ Core Relationship

Slice-based PDU Session Isolation

PerspectiveEffect
QoS SeparationURLLC and eMBB can meet delay•throughput requirements independently
Security IsolationIndustrial / public network traffic separated from consumer traffic
Resource ReservationDedicated resources per slice (scheduler, queue, buffer separation)
Fault IsolationFailure in one session does not affect sessions in other slices
Operational EfficiencyIndependent policy, charging, and SLA management per slice

PDU Session Establishment Process

1️⃣ UE Attach (Registration)

  1. UE → AMF : PDU Session request
  2. AMF → SMF : Session creation request
  3. SMF: Creates the default PDU Session

2️⃣ When an Application Starts

  1. The app opens a TCP/UDP socket, generating a new IP flow
  2. UE’s IP stack creates a new socket (e.g., TCP 443)
  3. Traffic is sent via the default session’s IP address (e.g., 10.10.0.12)
  4. UPF matches the packet to a PDR (Packet Detection Rule) based on its 5-tuple
  5. SMF policy decides whether to assign a new QFI within the same PDU Session or reuse an existing one
  6. If needed, the SMF requests a new QoS class (5QI) from the PCF

📋 A new PDU Session is created when

  1. The destination network differs (e.g., IMS, corporate VPN) ➔ specific DNN access needed
  2. A special network slice is required
  3. A premium or isolated service (e.g., high-quality streaming) demands QoS separation beyond a single QoS Flow

*️⃣ Multi-PDU Session Operation

When the UPF forwards an IP flow to the gNB using its TEID mapping, the gNB distinguishes which PDU Session the flow belongs to and applies the corresponding session configuration.

UPF Packet Processing

The UPF maintains a session table received from the SMF, which stores the following mappings:

KeyMappingDescription
(TEID, N3 interface)PDU Session IDIdentifies a GTP-U tunnel
(PDU Session ID, QFI)QoS FlowIdentifies QoS Flow within a session
(QoS Flow, PDR filter)IP Flow (5-tuple)Matches the actual application flow

The UPF also receives a preconfigured set of PDR / FAR / QER rules from the SMF:

Rule TypeKeyValueFunction
PDRPacket filter (5-tuple)QFIDetermines “which QoS Flow this packet belongs to”
FARQFIForwarding Action (includes TEID)Specifies “which tunnel to forward this flow through”
QERQFIRate / marking policyApplies “QoS limits such as rate or marking”

UPF packet handling sequence 👇

The UPF handles each packet following the sequence as below:

  1. PDR identifies the packet ➔ “This belongs to QoS Flow #7 (QFI=7)”
  2. FAR determines ➔ “QFI=7 should be sent via TEID=0xA12F (Session 001)”
  3. QER applies rate limiting or marking
  4. UPF encapsulates the packet with GTP-U (QFI + TEID) and forwards it to the RAN

Example: Two PDU Sessions on a Single UE

PDU SessionS-NSSAIDNNUE IPTEIDUPF PathTypical Traffic
#1eMBBinternet10.10.0.120xA12FUPF-AWeb / Video
#2URLLCmec.app.local10.20.0.450xB38EUPF-B (Edge)Real-time control

UPF packet handling example 👇

  1. If a packet arrives with GTP-U(TEID=0xA12F) ➔ belongs to PDU Session #1
  2. If a packet arrives with GTP-U(TEID=0xB38E) ➔ belongs to PDU Session #2
  3. Within each session, packets are further classified by QFI (QoS Flow)
  4. Then identified by PDR packet filter (5-tuple)
  5. Finally, FAR/QER policies for forwarding and rate control are applied

➡️ The UE’s modem maintains the PDU Session ID ↔ TEID mapping, and applies the correct GTP-U encapsulation during transmission.

  1. UE sends an IP flow → modem looks up the corresponding session’s TEID
  2. UE encapsulates the packet with TEID + QFI (GTP-U)
  3. UPF identifies the session by TEID → applies QoS processing by QFI → forwards to external network

4️⃣ Process in RAN (gNB)

The QFI / 5QI information is the key trigger that propagates QoS control signaling through all RAN layers (PDCP–RLC–MAC).

SDAP Layer — QFI Interpretation & DRB Mapping

🔗 QFI–DRB Mapping

QFI–DRB mapping can be either 1:1 or N:1 depending on policy.

PDCP Layer — QFI/5QI-Driven Behavior

Responsible for integrity protection, ciphering, reordering, and duplication.

QoS RequirementPDCP Behavior
Low latency (5QI = 1, 2)Minimize reordering, conservative ROHC, reduce unnecessary delay
High reliability (5QI = 4–7)Use PDCP duplication if needed (RLC-AM handles ARQ)
Throughput-oriented (eMBB)Aggressive ROHC, moderate reordering window, efficient batching

➡️ PDCP tunes the latency/reliability trade-off based on the 5QI characteristics of the QoS Flow(s) mapped to the DRB, while ARQ retransmissions are handled by RLC-AM.

RLC Layer — QFI/5QI-Driven Behavior

Performs segmentation/reassembly and ARQ (AM) or low-latency transmission (UM), then forwards RLC logical channel (DTCH) to the MAC layer.

QoS TypeRLC ModeKey Features
URLLC / low-latency (5QI=1,2)UM (Unacknowledged Mode)Fast, no retransmission (ARQ disabled)
eMBB / GBR (5QI=4~7)AM (Acknowledged Mode)Reliable via ARQ retransmissions (t-PollRetransmit, t-StatusProhibit, maxRetx, etc.)
mMTC / best effort (5QI=9)UM or AM (optional)Balance between resource use and reliability

➡️ The RLC mode of a DRB is configured by RRC based on the 5QI characteristics of the QoS Flow(s) mapped to that DRB (via PCF/SMF).

MAC Layer — QFI/5QI-Driven Scheduling & Resource Control

Handles PRB/RBG-level scheduling and HARQ processes, passing assigned resources to the PHY layer via DL-SCH/UL-SCH transport channels.

QoS AttributeMAC-Level Control
Priority LevelScheduler weights based on LC priority
Packet Delay Budget (PDB)Prioritize LCs nearing delay budget
PER (Packet Error Rate)MCS selection / HARQ retransmission tuning
GBR / non-GBRReserves resources for GFBR, distributes remaining to non-GBR flows

➡️ MAC scheduler dynamically allocates RBGs using LC QoS attributes (Priority, PDB, PER), which originate from the 5QI parameters of the QoS Flow(s) mapped to that LC.

Reference Specifications

*️⃣ Hierarchical QoS Management in 5G RAN

5G RAN controls QoS at multiple hierarchical levels, each operating at a different granularity.

Level 1: Network Slice (S-NSSAI) — Resource Partitioning Across UEs

Slice 1 (eMBB, S-NSSAI=1):
├─ DRB1, DRB2 (UE1)
├─ DRB1 (UE2)
└─ Slice-level policies:
   ├─ RAN resource allocation ratio (e.g., 50% PRB)
   ├─ Admission control
   └─ MAC scheduler policy (e.g., PF vs RR)

Slice 2 (URLLC, S-NSSAI=2):
├─ DRB3 (UE1)
├─ DRB1, DRB2 (UE3)
└─ Guarantees low latency and high reliability

Level 2: PDU Session — UE-Specific Connectivity Sessions

UE1:
├─ PDU Session 1 (internet, S-NSSAI=1)
│  └─ QoS Flow 1, 2, 3
└─ PDU Session 2 (IMS, S-NSSAI=2)
   └─ QoS Flow 4

Level 3: DRB (Data Radio Bearer) — Execution Unit in the RAN Stack

QoS Flows (QFIs) are the smallest QoS policy unit in the Core, but the RAN executes QoS at the DRB level, and after SDAP (PDCP–RLC–MAC), Flow-level distinctions no longer exist.

UE1:
├─ DRB1 ← QoS Flow 1, 2 (both 5QI=9, video)
├─ DRB2 ← QoS Flow 3 (5QI=5, IMS)
└─ DRB3 ← QoS Flow 4 (5QI=1, URLLC)

Level 4: QoS Flow — Fine-Grained QoS for Applications

💡 QoS Management Coordination

To guarantee end-to-end QoS across the hierarchy:

  1. Slice level: Proper partitioning of RAN resources
  2. Core (UPF): Fine-grained scheduling per QoS Flow
  3. SDAP: Efficient QoS Flow → DRB mapping
  4. RAN (PDCP/RLC/MAC): Correct per-DRB handling

In the downlink, packets are generated in the core network and pass through multiple entities. In contrast, uplink transmission starts entirely inside the UE.

1️⃣ Application – Transport – IP

Example: during a video conference

FunctionDescriptionExample QoS Flow
Video uploadUE camera streamQFI=5 (5QI=2)
Audio uploadMicrophone streamQFI=6 (5QI=1)
ChatText messagesQFI=7 (5QI=9)

2️⃣ SDAP

QoS Flow classification and mapping for uplink.

💡 Reflective QoS

Reflective QoS allows the UE to “mirror” the QoS of downlink traffic, ensuring that uplink packets from the same application are mapped to the same QoS Flow without requiring additional signaling.

How it works:
Benefits:

3️⃣ PDCP–RLC–MAC

4️⃣ UE → RAN (Physical Transmission)

Uplink Grant Decision Factors:
The uplink grant is determined by the gNB MAC scheduler considering BSR (Buffer Status Report), Channel quality (CQI), and QoS requirements of each LC/DRB

5️⃣ RAN → UPF

6️⃣ Internet Routing

Beyond the UPF, the uplink path follows the same routing process as downlink. It uses the MNO’s backbone routing tables to determine the next hop and traverses the Internet to reach the Application Server.

TypeDescriptionTypical Scenario
Scheduled Grant (SG)gNB periodically reserves uplink resourcesVoIP, periodic sensing, URLLC
Dynamic Grant (DG)UE requests uplink resources on demandVideo conference speech, file upload, event-driven traffic

Dynamic Grant Allocation Procedure

(1) Application Layer

(2) MAC Layer Arrival

(3) gNB Scheduling

(4) UE Transmission

Scheduled Grant Procedure

Used for periodic or continuous uplink traffic such as URLLC or VoIP.

1️⃣ SR Transmission Latency

The SR is sent through PUCCH (Physical Uplink Control Channel) or PRACH (Random Access Channel). Both are opportunity-based, not grant-free.

2️⃣ Scheduling Grant Response Delay

After receiving an SR, the gNB typically requires 2–4 TTIs (≈2–4 ms) to issue the grant.

It must check uplink load, HARQ status, and RBG availability, compute resource allocation per UE, and transmit the grant through the PDCCH, introducing processing and control delay.

Techniques for Reducing Dynamic Grant Latency

TechniqueConceptEffect
Semi-persistent scheduling (SPS)gNB pre-reserves uplink resourcesEliminates SR–Grant process, reduces delay
Configured grant (CG)UE preconfigures resources via RRC for periodic useDesigned for URLLC
Grant-free uplinkUE transmits immediately using available resourceslowest latency, higher collision risk
Predictive schedulinggNB predicts traffic patterns and issues proactive grantsReduces latency for dynamic traffic

🎯 User-to-User Transmission

End-to-End communication includes not only Application-to-User, but also User-to-User transmission. For example, in a video conferencing service, UE A shares its screen with UE B.

Transmission Path

‼️ Commercial applications such as Zoom, Teams, or KakaoCall always route traffic through an Application Server.

✅ However, certain services (e.g., V2X, PS-LTE, URLLC edge offload) can perform local routing or direct delivery within the Core or at a MEC (Local UPF) level.

Typical Video Conference Path

UE A ↔ gNB ↔ UPF ↔ Application Server ↔ UPF ↔ gNB ↔ UE B
  1. UE A sends RTP packets (video/audio) via uplink.
  2. gNB forwards them to the Core UPF.
  3. The UPF routes the packets to the Application Server through the operator’s IP backbone or public Internet.
  4. The server processes them (transcoding, mixing, encryption, logging).
  5. The processed streams are sent downlink to UE B, UE C, and others.

Exception 1 — MEC (Local UPF) Local Breakout

In this case, the Core partially acts as an Application Server. User-to-user delivery terminates inside the Core at the Local UPF.

✅ Example structure

UE A ↔ gNB ↔ Local UPF (MEC site)
                  ↙      ↘
              UE B      Application Server (backup)

✅ Typical use cases

This approach bypasses the Core entirely. Transmission occurs directly at the RAN layer.

Exception 3 — Inter-UE Routing within the Core

“Inter-UE UP path” defined in 3GPP TS 23.501 §5.6.7, this is Core-level UE↔UE direct routing.

If both UEs belong to the same PDU Session / DNN / Slice, the UPF can directly route packets between them.

✅ Example structure

UE A ↔ gNB ↔ UPF ↔ gNB ↔ UE B
               (no App Server)

Examples by Service Type

ServiceTransmission PathApp Server InvolvedCore Role
Zoom / Teams / KakaoUE ↔ Server ↔ UE✅ YesIP transit backbone
V2X / factory automationUE ↔ Local UPF ↔ UE❌ NoLocal routing
PC5 sidelinkUE ↔ UE❌ NoRAN control only
IPTV / XcastgNB ↔ multiple UE❌ NoRAN multicast

🧩 QoS Determinants across Layers

End-to-end QoS emerges from how multiple layers and network functions interact — from the sender’s transport behavior to the radio scheduler at the network edge.

Finally, we highlight how each layer’s algorithms and parameters shape the resulting performance.

🚦 Transport Congestion Control

Determines how fast the application injects packets into the network and how it reacts to congestion.

Both the choice of algorithm and its parameter tuning define the resulting latency, jitter, and throughput — even on the same path.

🔹 Applications select and tune CC mechanisms depending on service goals:

💡 Even small parameter adjustments can shift QoS outcomes dramatically:

This shows Transport tuning is as critical as scheduler design in lower layers.

🌐 Internet Routing

Once packets enter the Internet, they follow routing paths determined by pre-configured tables and dynamic routing protocols (e.g., BGP, OSPF).

This segment operates mainly as best effort, offering minimal QoS enforcement.

💡 Still, end-to-end latency and loss remain unpredictable beyond the operator’s control.

🧭 UPF Forwarding and Queuing

In the operator’s core, the User Plane Function (UPF) performs traffic classification and enforcement according to policies from SMF/PCF.

⚙️ UPF is thus the first real enforcement point translating abstract QoS policies into measurable flow behavior before RAN transmission.

📡 MAC scheduling

The MAC layer allocates radio resources per LC (Logical Channel = DRB) and determines the scheduling priority based on each LC’s QoS attributes (Priority, PDB, PER).

🧩 Scheduling considerations:

🎯 By combining these factors, the MAC scheduler allocates actual radio resources and enforces QoS at the physical layer.

✅ Conclusion

Understanding this E2E data flow reveals a critical insight:

5G QoS is not managed by a single entity, but emerges from the interaction of multiple layers.

This seemingly simple observation has profound implications for how we design, optimize, and troubleshoot 5G networks.

Key Observations

1. Distributed Control

2. Cross-Layer Dependencies

While each layer has its own role, they inevitably influence each other:

Uplink presents unique difficulties:

Open Questions

These observations lead to important research questions:

🤔 Which layer is the bottleneck?
(Does it depend on traffic type? Network load?)

🤔 How do layer-specific algorithms interact?
(Is BBR+PF better than CUBIC+RR? Why?)

🤔 Can we optimize E2E without explicit cross-layer signaling?
(Or do we need protocol changes?)

What’s Next

In my upcoming research, I’ll dive deeper into these questions through systematic experimental analysis.

🥅 The goal: understand when and where each layer matters most, and explore practical approaches to E2E QoS optimization in 5G networks.


📬 Interested in this topic? Feel free to reach out or follow for updates on my research!