5G Sidelink SDAP Overview and SL-DRB Mapping
SDAP also operates over the PC5 interface for NR sidelink. In this branch, the SDAP entity is destination-centric, maps a PC5 QoS flow to an SL-DRB, and follows cast-type-specific behavior for unicast, groupcast, and broadcast.
The sidelink branch looks similar to Uu SDAP in broad shape, but the details are different: the entity model is built around destination and cast type, unicast is the only sidelink case with a header-bearing SDAP data PDU, and Reflective QoS does not apply over PC5.
Quick facts
| Technology | 5G NR sidelink over PC5 |
|---|---|
| Area / Protocol | SDAP sidelink overview and PC5 QoS flow to SL-DRB mapping |
| Primary baseline | 3GPP TS 37.324 |
| Entity scope | Per Destination Layer-2 ID and cast type in the UE |
| Main mapping object | PC5 QoS flow to SL-DRB |
| Important limit | Reflective QoS is not supported over the PC5 interface |
What Sidelink SDAP Does Over PC5
Over the PC5 interface, the SDAP sublayer maps a PC5 QoS flow to a sidelink data radio bearer. This is the sidelink counterpart to QoS flow to DRB mapping on the Uu interface.
At a high level, sidelink SDAP receives SDAP SDUs from upper layers, selects an SL-DRB using stored mapping or default SL-DRB logic, optionally adds an SDAP header for supported unicast cases, and then hands the PDU to lower layers for transmission or retrieves the SDU on reception.
On the RRC side, the wider PC5 operating context is easiest to connect through NR system information for broadcast sidelink support and through RRCReconfiguration when dedicated sidelink bearer behavior is provisioned for the UE.
Sidelink SDAP Entity Model
For NR sidelink, the SDAP entity is configured per Destination Layer-2 ID and cast type in the UE. TS 38.300 expresses the same architecture as one SDAP entity per destination for one of unicast, groupcast, and broadcast.
This makes the sidelink SDAP entity model different from Uu SDAP. Uu SDAP is mainly session-centric through PDU session or MBS session association, while sidelink SDAP is destination-centric and explicitly cast-aware.
When reading traces, the most useful control-plane anchor here is RRCReconfiguration, because that is where dedicated radio and bearer context is typically updated, while 5G Sidelink UE Information NR helps frame the UE-side sidelink context that sits behind destination and cast-type behavior.
PC5 QoS Flow to SL-DRB Mapping
The main sidelink SDAP mapping function is the mapping between a PC5 QoS flow and an SL-DRB. This sits alongside QoS flow to DRB mapping and MBS QoS flow to MRB mapping as one of the three main mapping branches in the wider SDAP model.
On transmission, the sidelink SDAP entity uses either a stored PC5 QoS flow to SL-DRB mapping rule or the default SL-DRB when no stored rule exists. On reception, it retrieves the SDAP SDU from the received sidelink SDAP data PDU and delivers it upward.
The mapping parameters themselves are easier to interpret when read alongside RRCReconfiguration, because that is the message path that usually carries the dedicated sidelink bearer configuration which later becomes stored SDAP mapping state in the UE.
Default SL-DRB Behavior
Sidelink SDAP uses the same basic fallback idea as Uu SDAP: if no stored mapping rule exists for a PC5 QoS flow, the UE maps the SDU to the default SL-DRB when one is configured.
The exact RRC fields that control this live in SL-SDAP-Config-r16, which is why the detailed
configuration mechanics belong on the dedicated sidelink configuration page rather than on this overview page.
In practice, when you want to understand where the default sidelink bearer comes from, start with RRCReconfiguration and then map the delivered sidelink bearer settings to the SDAP-side fallback behavior described here.
Unicast, Groupcast, and Broadcast Context
Cast type is part of the sidelink SDAP identity model. The same destination logic does not apply identically across unicast, groupcast, and broadcast, so cast type needs to be treated as part of the SDAP entity context rather than as an optional side note.
This matters especially at the PDU level. The header-bearing sidelink SDAP data PDU format is defined for unicast, while groupcast and broadcast follow the headerless path.
The cast-type context is easier to reason about when paired with 5G Sidelink UE Information NR and the NR system-information view, because those RRC references help explain how sidelink feature context is exposed beyond the pure SDAP procedure text.
Reflective QoS Does Not Apply Over PC5
Reflective QoS is not supported over the PC5 interface. This is one of the clearest behavioral differences between sidelink SDAP and DRB-based Uu SDAP.
As a result, sidelink SDAP should not be described using RQI, RDI, or
RQ timer behavior. Those belong to the reflective QoS reading path for Uu SDAP, not to the PC5
sidelink branch.
Sidelink SDAP Transmit and Receive Model
On transmission, the sidelink SDAP entity receives an SDAP SDU for a PC5 QoS flow, selects an SL-DRB using stored mapping or default SL-DRB logic, constructs either a header-bearing or headerless SDAP data PDU as configured, and submits it to lower layers.
On reception, the sidelink SDAP entity receives the SDAP data PDU from lower layers, retrieves the SDAP SDU according to whether header presence is configured, and delivers the SDAP SDU to upper layers.
Sidelink SDAP vs Uu SDAP
| Aspect | Uu SDAP | Sidelink SDAP |
|---|---|---|
| Main mapping object | QoS flow to DRB | PC5 QoS flow to SL-DRB |
| Entity scope | Per PDU session or MBS session | Per destination and cast type |
| Reflective QoS | Supported where applicable | Not supported over PC5 |
| Header-bearing format | DL and UL cases where configured | Defined for unicast only |
How This Page Connects to SL-SDAP-Config
The behavior described here is configured by the sidelink RRC model through
TS 38.331 and its SL-SDAP-Config-r16 structures.
That configuration provides the fields used for sidelink header presence, default SL-DRB selection, mapped sidelink flows, and cast type. This overview page stays at the behavior and architecture layer, while the field-level configuration details belong on the dedicated SL-SDAP-Config page.
For live reading, start with RRCReconfiguration for dedicated parameter delivery, use 5G Sidelink UE Information NR for UE-side sidelink reporting context, and keep NR system information nearby when the sidelink behavior depends on broadcast feature support rather than only on dedicated configuration.
Reference Examples
Example 1: Unicast sidelink mapping
A UE has a stored PC5 QoS flow to SL-DRB mapping rule for a unicast destination. When an SDAP SDU arrives for that flow, sidelink SDAP maps it to the stored SL-DRB and constructs the appropriate sidelink SDAP data PDU.
Example 2: Default SL-DRB fallback
No stored mapping rule exists for a PC5 QoS flow, but a default SL-DRB is configured. The UE maps the SDU to the default SL-DRB and continues the sidelink transmit procedure.
Example 3: Why reflective QoS is excluded
A reader expects PC5 traffic to reuse the same reflective QoS logic as Uu SDAP. That expectation is incorrect because Reflective QoS is not supported over PC5.
Recommended Diagram Blocks
- PC5 QoS flow -> SL-DRB mapping diagram
- Sidelink SDAP entity per destination and cast type
- Transmit path:
upper layers -> SDAP -> SL-DRB -> lower layers - Receive path:
lower layers -> SDAP -> upper layers - Callout box:
Reflective QoS not supported over PC5
Key Specification References
- 3GPP TS 37.324 - primary SDAP specification for sidelink entity handling and PC5 QoS flow to SL-DRB mapping
- 3GPP TS 38.300 - NR architecture context for sidelink SDAP over PC5 and one-entity-per-destination behavior
- 3GPP TS 38.331 - RRC context for SL-SDAP-Config-r16 and sidelink SDAP control