SDAP Overview in 5G NR
The user-plane-only layer that sits above PDCP and handles QoS flows.
SDAP is the newest and topmost layer of the 5G user-plane stack. Its single job is to sit above PDCP and map QoS flows onto data radio bearers, because 5G decided QoS should be per-flow rather than per-bearer. It exists only on the user plane, there is exactly one entity per PDU session, and it is defined in TS 37.324.
Introduction
Service Data Adaptation Protocol (SDAP) is the layer 3GPP added at the very top of the NR user-plane protocol stack — above PDCP — when it moved 5G from LTE's per-bearer QoS to a per-flow QoS model. It is defined in TS 37.324, configured by RRC through the sdap-Config IE (TS 38.331), and serves the QoS model of TS 23.501. It runs on the user plane only; there is no SDAP on the control plane.
SDAP comes into existence the moment a PDU session is established: the UE and the gNB each instantiate exactly one SDAP entity for that session, and it lives as long as the session does. From then on, every user-plane packet of that session passes through SDAP on the way down (transmit) and on the way up (receive). Its work is small but structural — it is the hinge between the 5G core's flow-level QoS decisions and the radio's bearer structure.
Because it is thin and sits at the boundary between the NAS/core QoS model and the AS/radio bearers, SDAP is easy to underestimate. But it is exactly the layer that makes "many services, one PDU session, each with its own treatment" possible over the air, and understanding it is the key to reading the whole 5G QoS chain.
On this page
Why SDAP is needed
In plain words: think of a PDU session as one delivery truck driving from the core to the UE, and the QoS flows as parcels inside it, each with a coloured label (the QFI) saying how urgently it must be delivered. SDAP is the loading clerk at the back of the truck: it reads each parcel's label and drops it into the right sorting bin (the DRB) so voice, video and background sync each get the handling their label demands.
In LTE, QoS was bound to the bearer. Each EPS bearer carried a single QCI, one set of QoS parameters, and its own end-to-end tunnel; if you wanted different treatment you set up a different bearer. The mapping from traffic to QoS was fixed at bearer-establishment time and carried unchanged all the way through. There was no layer above PDCP because there was nothing to adapt — the bearer was the QoS. One EPS bearer meant one QoS, full stop.
5G decoupled QoS from the bearer. The finest unit of QoS is now the QoS flow, identified by a QFI, and many flows can live inside one PDU session and even share DRBs. The core no longer creates a separate bearer per QoS treatment; instead it marks each packet with a QFI and leaves the radio side to decide the flow-to-DRB mapping. That decision needs a home in the protocol stack, and that home is SDAP. It is the layer that did not need to exist when QoS was per-bearer, and became necessary the moment QoS went per-flow.
Mental model: LTE said "one pipe, one QoS." 5G says "one pipe (the PDU session) carrying many labelled streams (QoS flows), and a sorter (SDAP) that drops each stream into the right radio bearer." The label is the QFI; the sorter's rulebook is sdap-Config.
What SDAP Is
SDAP stands for Service Data Adaptation Protocol. When a PDU session is established, the UE and gNB each create one SDAP entity for that session. That entity receives IP packets already tagged by the 5G core with a QoS Flow Identifier (QFI) and decides which DRB each packet should ride on, optionally stamping an SDAP header onto the packet before handing it down to PDCP. On the receive side it does the reverse: reads or infers the flow, strips any header, and delivers the payload upward.
A thin adaptation layer above PDCP. One SDAP entity per PDU session, present on both UE and gNB, user plane only. It maps QoS flows → DRBs and may add an SDAP header carrying the QFI.
5G QoS is granular: many flows (voice, video, gaming, background sync) can share one PDU session, each with its own treatment. Something has to steer each flow to the right DRB — that something is SDAP.
It reads the QFI the core assigned, applies the mapping rules RRC gave it in sdap-Config, selects a DRB, and (if that DRB is configured for it) writes the SDAP header. Downlink it may also set the RQI/RDI bits that drive reflective QoS.
One-liner: SDAP is the layer that turns "per-flow QoS from the 5G core" into "which radio bearer do I put this packet on." It is the bridge between the 5G QoS model and the radio bearer structure below it.
Because SDAP is strictly user plane, the control plane has no equivalent. RRC and NAS signalling travel on Signalling Radio Bearers (SRBs) and carry no QoS-flow user traffic, so there is nothing for SDAP to map. The user-plane stack is SDAP → PDCP → RLC → MAC → PHY; the control-plane stack is identical below PDCP but has no SDAP on top.
LTE ↔ NR: LTE has no SDAP at all — the topmost user-plane layer is PDCP, and QoS is the EPS bearer (one QCI per bearer). NR inserts SDAP above PDCP purely to carry the flow-to-DRB mapping that per-flow QoS demands. Everything below PDCP (RLC, MAC, PHY) is otherwise structurally the same idea; SDAP is the one genuinely new user-plane layer in 5G.
The End-to-End QoS Chain
To see where SDAP fits you have to see the whole chain from the core down to the air. 5G QoS is a three-level hierarchy, and SDAP owns exactly the last hop of it — the step from QoS flow to radio bearer.
At the top, a PDU session is the logical connectivity between the UE and a data network (an IP anchor at the UPF). Inside it, the core sets up one or more QoS flows. Each QoS flow is the finest granularity of QoS differentiation in the system; it is identified by its QFI and characterised by a 5QI (5G QoS Identifier) that points to a standardised profile — resource type (GBR or non-GBR), priority level, packet delay budget, and packet error rate. The core enforces flow-level policy and marks every downlink packet with its QFI. Finally, SDAP maps each QoS flow onto a DRB, the radio-level bearer that PDCP/RLC actually carry over the air. Several flows may share one DRB, or a flow may get a DRB to itself.
The QFI is a 6-bit value, so a PDU session can hold up to 64 distinct QoS flows (values 0–63). The 5QI is an integer in the range 0–255, split into standardised values (fixed characteristics, defined in TS 23.501), operator-specific pre-configured values, and dynamically-assigned values (characteristics signalled explicitly per flow). Each DRB is named by a DRB-Identity (INTEGER 1–32, TS 38.331), which is why a UE tops out at a modest number of DRBs even while it may juggle many more QoS flows — another reason flows must be multiplexed onto shared bearers.
| Concept | Identified / defined by | Scope | Who owns it |
|---|---|---|---|
| QoS flow | QFI (0–63), with a 5QI profile | Finest QoS granularity within a PDU session | 5G core (SMF/UPF); enforced end-to-end |
| 5QI | Scalar index into standardised QoS characteristics (0–255) | Defines resource type, priority, delay budget, error rate | Standardised in TS 23.501; referenced by the flow |
| DRB | DRB-Identity (1–32, RRC) | Radio bearer carrying one or more flows over the air | gNB RAN; realised by PDCP/RLC/MAC |
A few example 5QI values make the hierarchy concrete. 5QI 1 is GBR conversational voice, 5QI 5 is non-GBR IMS signalling, 5QI 9 is the typical non-GBR "default internet" flow, and 5QI 82 is a delay-critical GBR profile for discrete automation. Voice (a GBR flow) and best-effort web traffic (a non-GBR flow) can co-exist inside one PDU session as two QoS flows with two different QFIs, and SDAP is what keeps them on the DRBs that give each the treatment its 5QI demands.
5QI | Resource type | Priority level | Packet Delay Budget | Packet Error Rate | Example service |
|---|---|---|---|---|---|
| 1 | GBR | 20 | 100 ms | 10−2 | Conversational voice |
| 2 | GBR | 40 | 150 ms | 10−3 | Conversational video (live) |
| 5 | Non-GBR | 10 | 100 ms | 10−6 | IMS signalling |
| 9 | Non-GBR | 90 | 300 ms | 10−6 | Default "internet" / buffered video |
| 82 | Delay-critical GBR | 19 | 10 ms | 10−4 | Discrete automation |
These are representative standardised entries from the TS 23.501 5QI-to-characteristics table; the point is the shape, not memorising rows — a lower priority-level number means higher scheduling priority, and the resource type (GBR / Non-GBR / Delay-critical GBR) decides whether the flow gets a guaranteed rate.
Spec anchor: The QoS model (PDU session, QoS flow, QFI, 5QI) is defined in TS 23.501. SDAP itself — the flow-to-DRB mapping and the header — is TS 37.324. The RRC configuration that ties them together (sdap-Config) is TS 38.331.
What the SDAP Entity Does
The functions of SDAP are deliberately small; TS 37.324 lists them tightly. There is one entity per PDU session, and it handles both directions of that session's traffic.
| Function | Meaning |
|---|---|
| QoS-flow → DRB mapping | For each packet, choose the DRB based on its QFI and the configured mapping rules. Many flows may map to one DRB. |
| SDAP header handling | If the DRB is configured with an SDAP header, add it on transmit (carrying the QFI, plus DL indications) and remove it on receive. |
Uplink QFI marking | Mark the uplink packet with its QFI so the mapping is visible to the gNB and the flow is identifiable end-to-end. |
| Reflective mapping support | React to the downlink RQI/RDI so the UE can derive its uplink QoS-flow-to-DRB mapping without explicit signalling (reflective QoS). |
| End-marker control PDU | On a mapping change, the UL entity may send an end-marker control PDU on the old DRB so the network knows the flow has moved. |
Notice what SDAP does not do: it does not cipher, it does not do integrity protection, it does not do reordering, retransmission, or duplication. Those belong to PDCP and below. SDAP is purely an adaptation and steering layer — it looks at the QFI, picks a DRB, and manages one small header. That minimalism is intentional; keeping SDAP thin means the heavy user-plane machinery stays in PDCP where it already lived in LTE.
SDAP defines exactly two PDU types, distinguished in the uplink by the D/C bit: the SDAP Data PDU (header, when present, plus the PDCP SDU) and the single SDAP Control PDU — the end-marker, carrying only the QFI of the flow being moved. There is no SDAP-level segmentation, sequence numbering, or ARQ; a Data PDU is one-to-one with a PDCP SDU.
The SDAP Header: QFI, RQI, RDI
When present, the SDAP header is a single octet prepended to the PDCP SDU. Whether it is present at all is a per-DRB choice made by RRC (see the next section) — and crucially the header format is not the same in the two directions, because the two directions have different jobs.
In the downlink, the header's top two bits carry the reflective-QoS signalling and the bottom six carry the flow identity: RDI (Reflective QoS flow to DRB mapping Indication), RQI (Reflective QoS Indication), then the 6-bit QFI. The gNB sets RDI to tell the UE "adopt this DL flow-to-DRB mapping for your uplink too," and sets RQI to tell the UE "derive/refresh the QoS rule for this flow" — both are the mechanics of reflective QoS, where the UE learns its uplink QoS behaviour by observing the downlink instead of being told by NAS.
In the uplink, there is no reflective signalling to send, so the top two bits are used differently: a D/C bit (Data or Control PDU — the control PDU being the end-marker) and one reserved bit R, followed by the same 6-bit QFI. The UE marks the flow it is sending; it never sets RQI/RDI.
| Bit (MSB → LSB) | Downlink SDAP Data PDU | Uplink SDAP Data PDU |
|---|---|---|
| Bit 1 (MSB) | RDI — reflective flow→DRB mapping indication | D/C — Data (1) vs Control/end-marker (0) |
| Bit 2 | RQI — reflective QoS indication | R — reserved (set to 0) |
| Bits 3–8 | QFI (6-bit, values 0–63) | QFI (6-bit, values 0–63) |
| Total size | 1 octet | 1 octet |
| Set by | gNB (network drives reflective QoS) | UE (marks the flow it sends) |
QFI; the top two bits differ — RDI/RQI downlink for reflective QoS, D/C/R uplink.The RQI/RDI bits are the hook into reflective QoS and reflective mapping, covered on their own page. In short: rather than signalling every uplink QoS rule and every uplink flow-to-DRB mapping explicitly, the network can let the UE mirror what it sees in the downlink. The SDAP header is the only place in the stack those two one-bit levers live.
Mapping QoS Flows to DRBs & the Default DRB
The core of SDAP is the mapping itself. Each downlink packet arrives already tagged with a QFI; SDAP looks up which DRB that QFI is mapped to and sends it down. In the uplink the UE applies the mapping rules RRC configured, or the ones it learned reflectively, to pick the DRB and mark the packet. Several QoS flows can be multiplexed onto one DRB, which is exactly why the header's QFI field matters — without it the receiver could not tell the multiplexed flows apart on the shared bearer. The relationship is strictly many-to-one: a DRB may carry several flows, but any one flow maps to exactly one DRB at a time.
What happens to a flow that has no explicit mapping rule? It goes to the default DRB. Every PDU session's sdap-Config designates exactly one DRB as defaultDRB, and any QoS flow not otherwise mapped is carried there. This guarantees there is never a flow with nowhere to go — the default DRB is the catch-all, and it is also the bearer the UE uses for a new uplink flow before it has learned a more specific mapping. When a flow's mapping changes from one DRB to another, the UE can transmit an end-marker control PDU on the old DRB so the network can reorder cleanly and know the switch is complete.
Why the header is mandatory for a multi-flow DRB: if two QFIs share one DRB, only the header's QFI field lets the receiver separate them again. A single-flow DRB can safely run headerless because the flow is implied by the bearer.
Configuring SDAP: sdap-Config
Although there is always exactly one SDAP entity per PDU session, almost everything about its behaviour on a given bearer is configured per DRB by RRC through the sdap-Config IE, which lives inside the DRB configuration (TS 38.331). This is where "one entity per PDU session, header per DRB" is actually expressed.
The key fields are pdu-Session (which PDU session, and therefore which SDAP entity, this DRB belongs to; INTEGER 0–255), sdap-HeaderDL and sdap-HeaderUL (each independently the enumerated value present or absent, so the header can be on in one direction and off in the other), defaultDRB (a BOOLEAN marking this DRB as the session's catch-all — at most one DRB per PDU session may set it), and mappedQoS-FlowsToAdd / mappedQoS-FlowsToRelease (SEQUENCEs of QFIs, each 0–63, explicitly mapped to or removed from this DRB). Together these keep RRC and SDAP in agreement about which flows belong where and whether a header is needed to tell them apart.
A DRB configured with the header present is the flexible case — it can multiplex several flows and support reflective QoS. A DRB with the header absent is the simple case — a single flow pinned to a single bearer, no per-packet QFI needed, mapping fixed. Both are valid; the network picks per DRB based on whether that bearer needs to carry more than one flow or participate in reflective QoS.
Configuration home: sdap-Config is carried in RRCReconfiguration inside each DRB's setup (DRB-ToAddMod). It names pdu-Session, sdap-HeaderDL, sdap-HeaderUL, defaultDRB, and the mapped QFI lists. Change the mapping and you send a new sdap-Config; the SDAP entity re-points the affected flows.
⚠ Common pitfalls / gotchas
- Multiplexing flows on a headerless DRB. If
sdap-HeaderDL/sdap-HeaderULisabsentbut more than oneQFIis mapped to the DRB, the receiver cannot separate the flows — a headerless DRB must carry exactly one flow. - Forgetting the default DRB. Every PDU session needs exactly one DRB with
defaultDRB=true; without it, an unmapped flow (or a new UL flow before reflection) has nowhere to go. - Confusing per-session and per-DRB scope. There is one SDAP entity per PDU session, but header presence, mapping and default-DRB status are all per DRB — a change to one DRB's
sdap-Configdoes not re-point flows on the others. - Expecting SDAP to protect data. SDAP does no ciphering, integrity or reordering; if a security or in-order-delivery symptom appears, the cause is in
PDCP, not SDAP.
Summary
SDAP is the one new user-plane layer 5G added, and it exists for exactly one reason: QoS went from per-bearer (LTE) to per-flow (NR), and something had to map QoS flows → DRBs. There is one SDAP entity per PDU session, it lives only on the user plane, and it is defined in TS 37.324.
Read it as three moving parts. The mapping steers each QFI-tagged packet to a DRB (many flows may share one DRB; anything unmapped falls to the defaultDRB). The header is a single octet carrying the 6-bit QFI plus — downlink only — the RDI/RQI reflective-QoS bits. The configuration lives per DRB in sdap-Config (pdu-Session, sdap-HeaderDL/UL, defaultDRB, mapped QFI lists) inside RRCReconfiguration.
If you remember one thing: SDAP is the hinge between the core's flow-level QoS decisions (QFI, 5QI, defined in TS 23.501) and the radio's bearer structure below it. Everything heavier — ciphering, integrity, reordering — stays in PDCP; SDAP just reads a label and picks a bin.
Quick Q&A
Q. How many SDAP entities does a UE have?
A. One per established PDU session. Each PDU session gets its own SDAP entity, which handles all the QoS flows of that session and maps them onto that session's DRBs.
Q. What are the fields of the SDAP header, and how do DL and UL differ?
A. Both are one octet with a 6-bit QFI. Downlink the top two bits are RDI and RQI (reflective QoS/mapping, set by the gNB); uplink they are D/C (data vs end-marker control PDU) and a reserved bit R, set by the UE.
Q. Why did LTE not need SDAP?
A. LTE QoS was per-bearer — one EPS bearer meant one QCI, so traffic-to-QoS mapping was fixed by the bearer itself. 5G made QoS per-flow (QFI), with many flows per PDU session, so a new layer was needed to map flows to DRBs.
Q. What is the default DRB for?
A. It is the catch-all bearer named by defaultDRB in sdap-Config. Any QoS flow without an explicit mapping rule is carried on it, so no flow is ever left unmapped; it is also where a new uplink flow starts before a specific mapping is known.
Q. When must a DRB carry the SDAP header?
A. When it multiplexes more than one QoS flow (the QFI field is the only way to separate them) or when it must support reflective QoS via the RQI/RDI bits. A single-flow DRB can run headerless.
Quick LTE 4G / 5G NR Interview Questions — QFI & DL Mapping
Q. How does the UE know which QoS Flow a given downlink packet belongs to, so it can map it to the right radio bearer?
A. SDAP marks each PDCP SDU going to lower layers with a QoS Flow ID (QFI) — for downlink, the UE reads the QFI the network included in the SDAP header (when reflective QoS or explicit mapping requires it) to identify which flow, and thus which QoS rules (like which uplink bearer to mirror it to), the packet belongs to.
Going deeper
SDAP's real work is the flow-to-DRB mapping and the one-octet header. Follow the mapping decision in detail, see how the RQI/RDI bits drive the UE's uplink behaviour, and place it all inside the wider QoS architecture.