5G SDAP Entity Handling and Data Transfer
This reference page explains how an SDAP entity is established, released, and used for uplink, downlink, and sidelink data transfer. It focuses on the SDAP procedure flow between upper layers, SDAP, and lower layers, including default bearer handling and SDAP header presence.
Quick facts
| Technology | 5G NR |
|---|---|
| Area / Protocol | SDAP entity handling and data transfer procedures |
| Primary baseline | 3GPP TS 37.324 |
| Main focus | Entity establishment and release, uplink transfer, downlink transfer, and sidelink transfer handling |
| Key bearer contexts | DRB, default DRB, MRB, SL-DRB, and default SL-DRB |
| Main companion specs | TS 38.331 for RRC control and TS 38.300 for PC5 entity context |
What This Page Covers
This reference page covers the SDAP procedures for entity handling and data transfer. That includes SDAP entity establishment, SDAP entity release, uplink transfer, downlink transfer, sidelink transmission, and sidelink reception.
SDAP Entity Handling Overview
An SDAP entity receives SDAP SDUs from upper layers and submits SDAP data PDUs to lower layers on the transmitting side. On the receiving side, it receives SDAP data PDUs from lower layers, retrieves the SDAP SDUs, and delivers them to upper layers.
For NR Uu, an SDAP entity is configured for each individual PDU session or MBS session. For NR sidelink, an SDAP entity is configured per destination and cast type.
SDAP Entity Establishment
When RRC requests SDAP entity establishment, the UE establishes the SDAP entity and then follows the uplink
and downlink procedures. For ordinary NR Uu handling, that request is typically carried in
RRCReconfiguration through bearer-related
SDAP-Config.
For NR sidelink, when RRC requests establishment for unicast, groupcast, or broadcast communication, the UE establishes the SDAP entity and follows the sidelink transmission and reception procedures through the sidelink bearer configuration path.
The practical trigger is usually RRCReconfiguration,
where bearer-related configuration carries SDAP-Config. The UE reads the session identity,
header-presence flags, default-bearer indication, and mapped-flow context, then either creates a new SDAP
entity or updates the existing one for that pdu-Session. After that, the bearer is associated
with the entity and the normal SDAP data-transfer procedures become active.
SDAP Entity Release
When RRC requests release of an SDAP entity, the UE releases the entity. The same high-level rule applies when RRC requests release for unicast, groupcast, or broadcast NR sidelink communication.
At the SDAP layer, release is intentionally simple. Once RRC removes the bearer or session context that was tied to the entity, the UE drops the SDAP association and the entity is no longer used for transfer. The important practical check is whether the bearer release and the SDAP release stay aligned in traces.
Uplink Data Transfer
When the transmitting SDAP entity receives an SDAP SDU from upper layers for a QoS flow, it first determines
whether a stored QoS flow to DRB mapping rule exists. If no stored rule exists, it maps the SDU
to the default DRB. Otherwise, it maps the SDU according to the stored QoS flow to DRB mapping
rule.
After bearer selection, SDAP checks whether the DRB is configured by RRC with SDAP header presence. If yes, it constructs the UL SDAP data PDU with header. If not, it constructs the UL SDAP data PDU without header and submits the result to lower layers.
The spec notes that UE behavior is not defined if there is neither a default DRB nor a stored QoS flow to DRB mapping rule for the QoS flow. It also notes that the default DRB is always configured with UL SDAP header.
The real decision ladder is mapping first, header choice second. SDAP does not begin by building a header. It first decides which bearer should carry the packet, either from a stored rule or the default DRB. Only after that does it decide whether the selected bearer requires the UL SDAP data PDU with header or without header.
Downlink Data Transfer
When the receiving SDAP entity receives an SDAP data PDU from lower layers, it first checks whether the PDU
was received from an MRB. If it was received from an MRB, it retrieves the SDAP SDU using the
data PDU without SDAP header.
For DRB-based reception, if the receiving DRB is configured with SDAP header presence, the SDAP entity
performs reflective QoS flow to DRB mapping, performs RQI handling, retrieves the SDAP SDU from
the DL SDAP data PDU with header, and delivers it to upper layers. If SDAP header is not configured, it
retrieves the SDAP SDU from the headerless DL SDAP data PDU and delivers it upward.
Downlink is where the receive-side split matters most. MRB reception is always the simple no-header path,
while DRB reception may involve SDAP header parsing, reflective QoS flow to DRB mapping, and
RQI handling before the SDU is delivered upward.
Sidelink Transmission
When the transmitting SDAP entity receives an SDAP SDU from upper layers for a PC5 QoS flow, it checks
whether a stored PC5 QoS flow to SL-DRB mapping rule exists. If no stored rule exists, it maps
the SDU to the default SL-DRB. Otherwise, it maps the SDU according to the stored PC5 QoS flow to
SL-DRB mapping rule.
If the selected SL-DRB is configured with SDAP header presence, the entity constructs the SL SDAP data PDU with header. Otherwise, it constructs the sidelink data PDU without SDAP header and submits it to lower layers.
Sidelink transmit closely mirrors uplink on the decision order: mapping first, header choice second. The
main change is the vocabulary and target bearer. SDAP now works with a PC5 QoS flow and an SL-DRB
rather than a Uu QoS flow and a DRB.
Sidelink Reception
When the receiving SDAP entity receives an SDAP data PDU from lower layers for a PC5 QoS flow, it checks whether the SL-DRB is configured with SDAP header presence. If yes, it retrieves the SDAP SDU from the SL SDAP data PDU with header. If not, it retrieves the SDAP SDU from the headerless SDAP data PDU and delivers it to upper layers.
Sidelink receive is deliberately simpler than Uu downlink receive. There is no reflective QoS branch over
PC5. The key question is only whether the configured SL-DRB uses the SDAP header, because that
decides how the SDU is recovered before delivery upward.
Uu vs Sidelink Data Transfer Comparison
| Aspect | NR Uu | NR sidelink |
|---|---|---|
| Flow identity | QoS flow | PC5 QoS flow |
| Bearer target | DRB or MRB | SL-DRB |
| Default bearer fallback | Default DRB | Default SL-DRB |
| Header-controlled reception behavior | Can trigger reflective mapping and RQI handling | No reflective QoS over PC5 |
| Entity association | PDU session or MBS session | Per destination and cast type |
How RRC Connects to SDAP Entity Handling
RRC is what causes SDAP entity establishment, configuration, reconfiguration, and release in the UE. On the
ordinary NR Uu path, the gNB typically delivers SDAP-Config inside
RRCReconfiguration as part of the bearer-related radio
configuration, and the UE confirms successful application with
RRCReconfigurationComplete. When the bearer or
session context is later removed, the release side is usually visible through
RRCRelease or another RRC-driven bearer-change path. Within
that configuration, instances with the same pdu-Session value correspond to the same SDAP entity.
For sidelink, SL-SDAP-Config-r16 is used on the sidelink reconfiguration path to configure the
SDAP parameters for a sidelink DRB, including header presence, default sidelink bearer, mapping, and
cast-type-related behavior. The repo does not yet have a dedicated message page for
RRCReconfigurationSidelink, so the best live reference today is the main
5G RRC protocol page together with the
RRC timers and constants page, which already calls out
the sidelink reconfiguration message family.
Key Implementation Notes
- uplink behavior depends first on stored mapping rule availability and then on default DRB fallback
- default DRB is always configured with UL SDAP header
- downlink MRB reception uses the no-header data PDU path
- reflective QoS processing happens on Uu downlink when the DRB has SDAP header configured
- reflective QoS is not supported over PC5 sidelink
Key Specification References
| Specification | Why it matters |
|---|---|
| 3GPP TS 37.324 | Primary SDAP procedure specification for entity handling and data transfer. |
| 3GPP TS 38.331 | RRC establishment, configuration, and release of SDAP entities and SDAP parameters. |
| 3GPP TS 38.300 | NR overall architecture and sidelink SDAP entity model over PC5. |