3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE
Menu

Home / 5G / Protocols / SDAP / QoS Flow to DRB Mapping and Default DRB

5G SDAP QoS Flow to DRB Mapping and Default DRB

This page explains how SDAP maps QoS flows to DRBs, how default DRB fallback works for uplink packets, how reflective mapping is derived at the UE, and how DRB release affects stored mapping rules.

Quick facts

Technology 5G NR
Area / Protocol SDAP QoS flow to DRB mapping and default DRB behavior
Primary baseline 3GPP TS 37.324
Main focus Mapping configuration, default DRB fallback, reflective mapping, remapping, and DRB release cleanup
Key RRC fields pdu-Session, defaultDRB, mappedQoS-FlowsToAdd, mappedQoS-FlowsToRelease, sdap-HeaderDL, and sdap-HeaderUL
Main companion specs TS 38.331 for configuration and TS 38.300 for SDAP context

What This Page Covers

This reference page covers the SDAP rules for QoS flow to DRB mapping, including configuration, default DRB behavior, reflective QoS flow to DRB mapping, remapping, and DRB release handling.

Why QoS Flow to DRB Mapping Exists

SDAP is the user-plane layer that connects QoS-flow-level treatment to radio bearer transport. A QoS flow identifies service treatment, while the DRB is the bearer that carries the packet across the air interface. SDAP maintains the mapping relationship between them.

In uplink transmission, the UE needs a rule that tells it which DRB should carry a packet for a given QoS flow. If no stored rule exists, SDAP may use the default DRB for that PDU session.

Why the mapping layer exists
QoS flow to DRB mapping purpose A packet belongs to a QoS flow, SDAP uses mapping logic, and the packet is sent on the selected DRB across the radio interface. QoS flow Service treatment context SDAP mapping logic Stored mapping rule or default DRB fallback DRB Bearer used on the radio side

Configuration of QoS Flow to DRB Mapping

A QoS flow to DRB mapping rule can be configured by RRC. For each configured DRB, the associated SDAP-Config can indicate whether that DRB is the default DRB for the PDU session and which QFI values are additionally mapped to that DRB.

All configured instances of SDAP-Config with the same pdu-Session correspond to the same SDAP entity. Among those instances, defaultDRB may be set to true in at most one instance, and a QFI may appear at most once across all configured mappedQoS-FlowsToAdd lists for the same PDU session.

Configuration source

In live traces this configuration usually appears through RRCReconfiguration, because bearer-related changes and SDAP-Config ride together there.

Default DRB Behavior

The default DRB is the fallback bearer used when the transmitting SDAP entity receives an uplink SDU for a QoS flow and no stored QoS flow to DRB mapping rule exists for that flow.

defaultDRB is signaled at RRC level, and the SDAP uplink procedure uses that configured default DRB as the fallback target. The spec also states that the default DRB is always configured with UL SDAP header.

Important behavior

If there is neither a stored mapping rule nor a default DRB for the QoS flow, UE behavior is not defined by the SDAP spec.

Explicit Mapping and Additional QFI Association

Explicit QoS flow to DRB mapping is configured through the list of mappedQoS-FlowsToAdd values in SDAP-Config. Each listed QFI identifies an uplink QoS flow of the PDU session that is additionally mapped to the corresponding DRB.

This lets SDAP maintain per-QFI mapping state instead of relying only on default DRB fallback. Once such a mapping rule is stored, uplink packets for that QFI use the mapped DRB instead of the default path.

Reflective QoS Flow to DRB Mapping

Reflective QoS flow to DRB mapping is UE-side mapping behavior derived from downlink SDAP processing rather than only from explicit uplink configuration. In the SDAP architecture, reflective mapping is supported for uplink SDAP data PDUs when applicable.

In downlink SDAP processing, reflective mapping is triggered when a DRB is configured with SDAP header presence. That downlink header processing can provide the information the UE uses to update its uplink mapping behavior.

Reflective Mapping Limits and Scope

Reflective QoS mapping applies to QoS flow to DRB behavior on the Uu side. It does not apply to MRB in the same way, and it is not supported over the PC5 interface for sidelink.

That means reflective mapping belongs here as part of ordinary QoS-flow-to-DRB behavior, not as a generic rule across every SDAP transport case.

QoS Flow Remapping Behavior

QoS flow remapping is handled by reconfiguration of the SDAP entity. For remapping, the QFI of the remapped QoS flow is included only in mappedQoS-FlowsToAdd for the new DRB and is not included in mappedQoS-FlowsToRelease for the old DRB.

During reconfiguration, if a QFI added in mappedQoS-FlowsToAdd was already configured elsewhere, the UE releases that QFI from the old DRB and keeps the new association.

Call Flow: Remapping a QFI from one DRB to another
QFI remapping call flow RRC reconfiguration adds the QFI to the new DRB, the UE removes the old association, and future uplink packets use the new DRB. gNB / RRC UE SDAP entity Mapping state 1. RRC adds QFI to new DRB mappedQoS-FlowsToAdd 2. UE detects existing rule Old DRB association found 3. Old mapping removed New DRB becomes active 4. Future packets use the new DRB

DRB Release and Mapping Cleanup

When a DRB is released, the SDAP entity updates its stored QoS flow to DRB mapping state accordingly. This prevents stale mapping rules from continuing to point to a bearer that no longer exists.

The dedicated DRB release behavior belongs to the SDAP mapping procedures and should be treated as part of mapping-state maintenance rather than as a pure bearer-management topic.

Practical SDAP Mapping Model

  1. RRC establishes one SDAP entity for the PDU session.
  2. One DRB may be flagged as the default DRB.
  3. Specific QFIs may be explicitly mapped to DRBs.
  4. Downlink SDAP header processing may update UE-side reflective mapping.
  5. Reconfiguration can move a QFI from one DRB to another.
  6. DRB release removes obsolete mapping state.

Reference Examples

Example 1: No explicit mapping rule exists

A UL packet arrives for a QoS flow. The UE has no stored mapping rule for that QFI. If a default DRB exists for the PDU session, SDAP maps the packet to the default DRB and sends it with UL SDAP header.

Example 2: Explicit mapping overrides default fallback

QFI 9 is listed in mappedQoS-FlowsToAdd for DRB 2. When a UL SDU for QFI 9 arrives, SDAP uses DRB 2 instead of relying on default DRB fallback.

Example 3: Remapping during reconfiguration

A QFI previously associated with DRB 2 is added under the new DRB's mappedQoS-FlowsToAdd list. The UE releases the old association and uses the new DRB after reconfiguration.

Key RRC Fields Behind SDAP Mapping

Field Why it matters
pdu-Session Groups SDAP-Config instances into the same SDAP entity.
defaultDRB Marks the fallback DRB for the PDU session.
mappedQoS-FlowsToAdd Adds QFI-to-DRB associations.
mappedQoS-FlowsToRelease Releases existing associations from a DRB.
sdap-HeaderDL Controls whether downlink SDAP header is present and whether reflective processing can occur on that DRB.
sdap-HeaderUL Controls UL SDAP header presence and is set to present when the DRB is the default DRB.

Key Specification References

Specification Why it matters
3GPP TS 37.324 Primary SDAP mapping procedures: configuration, reflective mapping, and DRB release.
3GPP TS 38.331 RRC SDAP-Config fields for default DRB and QFI mapping control.
3GPP TS 38.300 Overall NR SDAP context and architectural limits such as PC5 reflective QoS non-support.

Next SDAP Reference Pages

Related Content