Protocol Stack

SDAP Layer —
QoS flows to radio bearers

SDAP is new in 5G NR — it has no equivalent in LTE. The Service Data Adaptation Protocol maps QoS flows (the 5GC's unit of QoS differentiation) onto data radio bearers. This section explains QoS flow identifiers, the mapping rules, and how SDAP enables differentiated treatment of traffic in the RAN.

TS 37.324 TS 23.501 §5.7 TS 38.300 §6.2

Why SDAP is needed

In 5G, the core network (5GC) handles QoS at the granularity of QoS flows. Each PDU session can carry multiple QoS flows — one for video streaming, one for voice, one for background data — each with different guaranteed bit rate and priority requirements.

The RAN handles QoS at the granularity of Data Radio Bearers (DRBs). There can be at most 29 DRBs per UE. SDAP bridges the two — it maps QoS flows (possibly many) onto DRBs (fewer, grouped by similar QoS requirements).

SDAP performs mapping between QoS flows and data radio bearers, and marks the DL and UL packets with QoS Flow ID (QFI). The QFI is used to differentiate packets with different QoS requirements within a PDU session.
3GPP TS 37.324, Section 4.2

QoS flow identifiers (QFI)

Each QoS flow is identified by a 6-bit QFI (QoS Flow Identifier) within a PDU session. The 5GC assigns QFIs based on the QoS requirements negotiated during PDU session establishment.

QoS flow types and their 5QI valuesTS 23.501 §5.7.4, Table 5.7.4-1
5QIResource typePriorityPacket delay budgetUse case
1GBR20100 msConversational Voice (VoNR) ← our call
2GBR4150 msConversational Video
5Non-GBR10100 msIMS Signalling
8Non-GBR8300 msVideo streaming (buffered)
9Non-GBR9300 msVideo streaming (default) ← YouTube
80Non-GBR6810 msLow latency gaming/URLLC

QoS flow to DRB mapping

The gNB's SDAP layer establishes a mapping table: each QFI maps to exactly one DRB. Multiple QFIs with similar QoS requirements can share one DRB. The mapping is configured by RRC in sdap-Config.

SDAP mapping — our UE's PDU sessionTS 37.324 §5.2
// PDU Session 1 (Internet): 3 QoS flows
QFI=1  (5QI=1,  VoNR voice)       → DRB1  (high priority, low latency)
QFI=5  (5QI=5,  IMS signalling)   → DRB1  (same DRB — both IMS)
QFI=9  (5QI=9,  best-effort data) → DRB2  (lower priority)

// SDAP header added to each DL PDU:
// 1 byte: RDI=0, RQI=0, QFI=1
[SDAP: 0x01] [IP packet for VoNR]  → sent on DRB1
[SDAP: 0x09] [YouTube UDP]         → sent on DRB2

// UL reflective QoS mapping:
// UE copies QFI from DL → UL for same flow
// (RQI bit = 1 triggers this mapping)

Full protocol stack — end to end

Now all four layers are covered. Here is how a VoNR voice packet travels from the network application to the radio interface:

Complete protocol stack — DL VoNR packet processing TS 38.300 §6.2
Overhead calculation — VoNR 40-byte payloadEach layer adds headers
// Application generates: 40 bytes RTP voice payload
IP + UDP + RTP headers: + 40 bytes → 80 bytes total

// SDAP:
SDAP header:           + 1 byte  → 81 bytes

// PDCP:
PDCP SN (12-bit):      + 2 bytes
MAC-I integrity:       + 4 bytes  ← only SRBs, not DRBs
After ROHC compression: IP+UDP+RTP → 2 bytes
Net PDCP output:       = 45 bytes  (40 payload + 2 ROHC + 2 PDCP hdr + 1 SDAP)

// RLC:
RLC-AM header:         + 2 bytes  → 47 bytes

// MAC:
MAC subheader:         + 2 bytes  → 49 bytes (+ padding to TBS)

// Without ROHC: 80 bytes payload → 86 bytes total  (+7.5% overhead)
// With ROHC:    42 bytes payload → 49 bytes total  (+16% overhead, less raw data)
// ROHC savings: 80→49 bytes = 39% reduction in bytes transmitted
Protocol stack complete — the full journey
SDAP        → QFI tagging, QoS flow → DRB mapping
PDCP        → AES ciphering + ROHC header compression
RLC         → AM segmentation + ARQ retransmission
MAC         → Multiplexing + HARQ + scheduling
PHY         → LDPC encoding + 256-QAM + OFDM → air