5G SL-SDAP-Config and Cast Types

Quick facts

What SL-SDAP-Config-r16 Is

SL-SDAP-Config-r16 is the NR RRC information element used to configure SDAP behavior for a sidelink DRB. Its core fields are the sidelink SDAP header presence flag, the default sidelink bearer flag, the mapped sidelink QoS flows, and the cast type.

The usual message-level place to look for these parameters is RRCReconfiguration, while 5G Sidelink UE Information NR and NR system information help frame the wider sidelink context around those dedicated settings.

ASN.1 Structure to Surface

The compact view to keep in mind is simple: one IE carries the sidelink SDAP header flag, the default bearer flag, the mapped QoS-flow information, and the cast type. For dedicated mapping updates, the configuration expands into dedicated add and release lists.

SL-SDAP-Config-r16 ::=
{
  sl-SDAP-Header-r16,
  sl-DefaultRB-r16,
  sl-MappedQoS-Flows-r16,
  sl-CastType-r16
}

SL-MappedQoS-FlowsListDedicated-r16 ::=
{
  sl-MappedQoS-FlowsToAddList-r16,
  sl-MappedQoS-FlowsToReleaseList-r16
}

This is most useful when read alongside RRCReconfiguration, because that is the point where these fields are typically introduced or updated for the affected sidelink bearer context.

sl-SDAP-Header-r16

sl-SDAP-Header-r16 indicates whether an SDAP header is present on the sidelink DRB. This directly controls whether the sidelink transmit and receive path uses a header-bearing or headerless SDAP data PDU.

This field matters especially because the header-bearing sidelink SDAP data PDU format is defined for unicast, while groupcast and broadcast rely on the headerless path. The wire-format consequence is easiest to follow by reading this field together with the dedicated config in RRCReconfiguration.

sl-DefaultRB-r16

sl-DefaultRB-r16 indicates whether the sidelink DRB is the default bearer for the NR sidelink communication transmission destination. Among configured SL-SDAP-Config instances for that destination, this field may be true in at most one instance.

At the SDAP procedure layer, this is the bearer used when no stored PC5 QoS flow to SL-DRB mapping rule exists for the incoming SDAP SDU. In trace reading, start with RRCReconfiguration and then map the delivered field value to the default SL-DRB fallback behavior seen in the SDAP procedure path.

sl-MappedQoS-Flows-r16

sl-MappedQoS-Flows-r16 is the field used to indicate which QoS flows are mapped to the sidelink DRB. If the field is included in dedicated signaling, it is set to the dedicated mapped-flow structure; otherwise it is set to the general mapped-flow list form.

This is the RRC-side bridge between the configuration payload in RRCReconfiguration and the stored PC5 QoS flow to SL-DRB mapping state later used by the sidelink SDAP transmit procedure.

Flow-List Modes in SL-SDAP-Config-r16

The general list form carries the set of QoS profiles mapped to the sidelink DRB. The dedicated form supports incremental add and release behavior through separate lists, which is the more useful view during reconfiguration.

The dedicated form is usually the easier one to reason about in RRCReconfiguration, because it makes it clear whether a flow is being added, removed, or effectively remapped.

sl-MappedQoS-FlowsToAddList-r16

sl-MappedQoS-FlowsToAddList-r16 indicates the list of sidelink QoS flow IDs of the NR sidelink communication transmission destination that are additionally mapped to this sidelink DRB.

In practical terms, this is the RRC-side mechanism for creating explicit PC5 QoS flow to SL-DRB mapping state. When you want to understand why a packet no longer follows default SL-DRB fallback, this add list is one of the first fields to inspect in RRCReconfiguration.

sl-MappedQoS-FlowsToReleaseList-r16

sl-MappedQoS-FlowsToReleaseList-r16 indicates the list of sidelink QoS flow IDs to be released from existing QoS-flow-to-SLRB mapping for this sidelink DRB.

This is the RRC-side mechanism for removing obsolete mapping state during sidelink reconfiguration. It becomes especially important when older mapping state would otherwise keep steering PC5 QoS flows toward the wrong sidelink bearer after an update.

sl-CastType-r16

sl-CastType-r16 is an enumerated field with values broadcast, groupcast, and unicast. It is not just a label in the configuration. It is one of the identity fields that define which sidelink SDAP context is in scope.

This matters because the sidelink SDAP entity model is destination- and cast-type-aware rather than PDU-session-based. The most useful control-plane companions here are 5G Sidelink UE Information NR and NR system information, because they help frame how the sidelink feature and cast context exists around the dedicated bearer configuration.

How Cast Type Changes SDAP Interpretation

Cast type affects which sidelink SDAP entity is in scope and also connects directly to the wire-format split: unicast may use the header-bearing sidelink SDAP data PDU, while groupcast and broadcast rely on the headerless path.

This is why sl-CastType-r16 should be treated as part of the real SDAP interpretation, not as a decorative field in the ASN.1.

How SL-SDAP-Config-r16 Maps to SDAP Behavior

1. sl-CastType-r16 identifies the sidelink communication mode.
2. sl-DefaultRB-r16 defines the fallback SL-DRB for the destination.
3. sl-MappedQoS-FlowsToAddList-r16 creates explicit PC5 QoS flow to SL-DRB rules.
4. sl-MappedQoS-FlowsToReleaseList-r16 removes existing rules.
5. sl-SDAP-Header-r16 controls whether the sidelink DRB uses an SDAP header.

At the SDAP procedure layer, if no stored PC5 QoS flow to SL-DRB mapping rule exists, the UE maps the SDAP SDU to the default SL-DRB; if a stored rule exists, it uses that mapping instead. The fastest way to connect those procedures back to signaling is to line them up with the relevant RRCReconfiguration that delivered or changed the configuration.

Relationship to End-Marker on Remapping

For unicast sidelink, reconfiguration of PC5 QoS flow to SL-DRB mapping can trigger End-Marker transmission. When a configured mapping rule differs from the stored one and the old SL-DRB has SL SDAP header configured, the UE constructs an End-Marker, maps it to the old SL-DRB, submits it to lower layers, and then stores the new rule.

This is why the add and release fields in RRCReconfiguration are not only bookkeeping. They can directly lead to a visible control-PDU effect in the sidelink SDAP procedure path.

Important Sidelink Limits

• Reflective QoS is not supported over the PC5 interface.
• Sidelink SDAP is configured per destination and cast type, not per PDU session.
• At most one default sidelink DRB may be configured for a given destination.

Reference Examples

Example 1: Default SL-DRB

A destination has two sidelink DRBs, but only one has sl-DefaultRB-r16 = true. When a PC5 QoS flow has no stored mapping rule, SDAP uses that default SL-DRB.

Example 2: Explicit add list

A dedicated reconfiguration includes sl-MappedQoS-FlowsToAddList-r16 for a specific sidelink DRB. The UE treats those flow IDs as additionally mapped to that bearer and stops relying on default fallback for those flows.

Example 3: Cast-aware context

Two sidelink communications may use the same destination identity but differ in cast type. The SDAP context still distinguishes them because cast type is part of the sidelink entity model and configuration.

Suggested ASN.1 View for the Page

The best presentation for this page is a compact annotated block for SL-SDAP-Config-r16 and its dedicated mapped-flow substructure, with callouts for header presence, default bearer, mapped flow lists, and cast type.

SL-SDAP-Config-r16 ::=
{
  sl-SDAP-Header-r16,
  sl-DefaultRB-r16,
  sl-MappedQoS-Flows-r16,
  sl-CastType-r16
}

SL-MappedQoS-FlowsListDedicated-r16 ::=
{
  sl-MappedQoS-FlowsToAddList-r16,
  sl-MappedQoS-FlowsToReleaseList-r16
}

Key Specification References

• 3GPP TS 38.331 - primary RRC specification for SL-SDAP-Config-r16 field definitions and constraints
• 3GPP TS 37.324 - sidelink SDAP behavior for PC5 QoS flow to SL-DRB mapping and default SL-DRB use
• 3GPP TS 38.300 - NR architecture context for sidelink SDAP entity scope and PC5 limitations

Next SDAP Reference Pages