5G RRC SDAP-Config, Default DRB, and QFI Mapping

Quick facts

What This Page Covers

This reference page covers the NR RRC fields that directly control SDAP behavior for DRBs. It focuses on the SDAP-Config IE and how each field translates into SDAP entity creation, header use, default bearer fallback, and QFI-to-DRB mapping state.

The main signaling path to keep in mind is RRCReconfiguration, followed by RRCReconfigurationComplete when the UE has applied the new bearer and SDAP settings.

What SDAP-Config Is in NR RRC

SDAP-Config is the NR RRC information element used to configure SDAP behavior for a DRB associated with a PDU session.

When sdap-Config is received, the UE configures the SDAP entity accordingly and associates the DRB with that SDAP entity. If the SDAP entity for the received pdu-Session does not yet exist, the UE establishes it.

In practice, this SDAP-bearing configuration is usually delivered in RRCReconfiguration inside the radio bearer configuration for the affected DRB.

How RRC Creates the SDAP Entity

The pdu-Session field is what ties an RRC SDAP-Config instance to a specific SDAP entity. All configured instances of SDAP-Config with the same pdu-Session correspond to the same SDAP entity.

This means one PDU session can have multiple DRBs configured through separate SDAP-Config instances while still belonging to the same SDAP entity.

The creation checkpoint on the air interface is again RRCReconfiguration. The success checkpoint is the UE answer in RRCReconfigurationComplete.

Core SDAP-Config Fields

These fields are typically read from the RRCReconfiguration payload, usually under bearer-related configuration for the DRB being added or modified.

pdu-Session and SDAP Entity Grouping

The pdu-Session field is not just a label. It is the key that defines which DRBs belong to the same SDAP entity.

Because all SDAP-Config instances with the same pdu-Session correspond to one SDAP entity, this field is what makes defaultDRB and per-QFI mappings meaningful across multiple DRBs of the same session.

When troubleshooting, read the pdu-Session grouping across repeated RRCReconfiguration messages rather than looking at only one DRB in isolation.

sdap-HeaderDL and sdap-HeaderUL

These two fields control whether SDAP uses header-bearing PDU formats for the DRB in downlink and uplink directions.

• sdap-HeaderDL enables or disables the DL SDAP header on the DRB.
• sdap-HeaderUL enables or disables the UL SDAP header on the DRB.

This directly affects whether SDAP constructs or receives header-bearing SDAP PDUs for that bearer and whether downlink reflective processing can be triggered on that DRB.

The fields themselves are configured in RRCReconfiguration, while the proof that the UE accepted the header-bearing DRB settings is the corresponding RRCReconfigurationComplete.

defaultDRB

The defaultDRB flag marks the DRB that SDAP uses as the fallback bearer for uplink packets when there is no stored QoS flow to DRB mapping rule for the flow.

For a given PDU session, defaultDRB may be set to true in at most one SDAP-Config instance. The SDAP spec also notes that the default DRB is always configured with uplink SDAP header.

In trace work, the relevant message to inspect is RRCReconfiguration, because that is where the network marks which DRB becomes the default bearer for the PDU session.

mappedQoS-FlowsToAdd

mappedQoS-FlowsToAdd is the field used by RRC to add explicit QFI-to-DRB associations for the PDU session.

Each listed QFI identifies an uplink QoS flow that is additionally mapped to the corresponding DRB. Across all SDAP-Config instances belonging to the same PDU session, a given QFI may appear at most once in mappedQoS-FlowsToAdd.

The operational message checkpoint is RRCReconfiguration, because this is the message that adds or changes the explicit QFI list for the target DRB.

mappedQoS-FlowsToRelease

mappedQoS-FlowsToRelease is used to remove existing QFI-to-DRB associations from a bearer.

This is the RRC-side mechanism for clearing mapping state during bearer reconfiguration and plays directly into SDAP remapping behavior.

The same release-style cleanup is usually signaled in RRCReconfiguration. If the radio context itself is being torn down rather than remapped, the wider session may later end with RRCRelease.

How Remapping Is Signaled in RRC

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.

If a QFI added in mappedQoS-FlowsToAdd was already configured in another DRB of the same SDAP entity, the UE releases that QFI from the old DRB. This is how RRC reconfiguration drives SDAP remapping without leaving conflicting state behind.

The relevant signaling pair here is RRCReconfiguration for the remap instruction and RRCReconfigurationComplete for the UE confirmation after the new mapping has been applied.

How RRC Fields Translate Into SDAP Behavior

1. pdu-Session selects the SDAP entity.
2. sdap-HeaderDL and sdap-HeaderUL select header-bearing SDAP PDU use.
3. defaultDRB provides fallback uplink bearer selection.
4. mappedQoS-FlowsToAdd creates explicit QFI-to-DRB mapping state.
5. mappedQoS-FlowsToRelease removes obsolete mapping state.
6. Reconfiguration may trigger End-Marker transmission before the new mapping becomes active.

End to end, this behavior is normally visible across one RRCReconfiguration plus the matching RRCReconfigurationComplete, with later user-plane traffic proving that the SDAP state is now in use.

Configuration Constraints Worth Surfacing

• All SDAP-Config instances with the same pdu-Session belong to the same SDAP entity.
• At most one DRB in that group may have defaultDRB = true.
• A QFI may appear at most once across all mappedQoS-FlowsToAdd entries for the same PDU session.
• When defaultDRB is true, the network sets sdap-HeaderUL to present.

These are the checks to apply while reading a single RRCReconfiguration or comparing multiple reconfiguration messages over time.

Reference Examples

Example 1: Creating a default DRB

A DRB is configured with defaultDRB = true, sdap-HeaderUL = present, and no explicit QFI list. This DRB becomes the fallback bearer for QoS flows in that PDU session that do not yet have stored explicit mappings.

Relevant message path: RRCReconfiguration carries the DRB settings, and RRCReconfigurationComplete confirms that the UE applied them.

Example 2: Adding an explicit QFI mapping

Another DRB in the same pdu-Session is configured with mappedQoS-FlowsToAdd = {QFI 9}. The UE stores QFI 9 as mapped to that DRB rather than using default fallback.

Relevant message path: RRCReconfiguration updates the mapping list for the DRB, and the UE acknowledges in RRCReconfigurationComplete.

Example 3: Remapping a QFI

During reconfiguration, QFI 9 is included only in mappedQoS-FlowsToAdd for the new DRB. The UE removes the old association and applies the new mapping, with SDAP procedure logic handling any required End-Marker transmission.

Relevant message path: the remap is signaled in RRCReconfiguration, and the completion checkpoint is RRCReconfigurationComplete.

Suggested ASN.1 View for the Page

A compact engineering view of SDAP-Config is usually more useful than a raw ASN.1 dump:

SDAP-Config ::=
{
  pdu-Session,
  sdap-HeaderDL,
  sdap-HeaderUL,
  defaultDRB,
  mappedQoS-FlowsToAdd,
  mappedQoS-FlowsToRelease
}

The main value is not the field names alone, but understanding how each one maps to header use, default bearer behavior, explicit QFI association, and remapping logic inside SDAP.

In live traces, this ASN.1 view is most often decoded from RRCReconfiguration.

Key Specification References

• 3GPP TS 38.331 - primary RRC specification for SDAP-Config field definitions and configuration rules
• 3GPP TS 37.324 - SDAP behavior that uses default DRB, header presence, and QFI-to-DRB mapping configured by RRC
• 3GPP TS 38.300 - NR architecture context for SDAP entity and DRB relationship

Next SDAP Reference Pages