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

Home / 5G / Protocols / SDAP / Architecture, Services, and Functions

5G SDAP Architecture, Services, and Functions

This reference page explains the SDAP architecture, including SDAP entity behavior, protocol stack position, services, lower-layer assumptions, and the main SDAP functions across NR Uu, MBS, and sidelink communication.

Quick facts

Technology 5G NR
Area / Protocol SDAP architecture, services, and functions
Primary baseline 3GPP TS 37.324
Main concerns SDAP entity model, protocol placement, service model, mapping behavior, and supported function set
Key architecture contexts NR Uu, MBS, and NR sidelink
Main companion specs TS 38.300 and TS 38.331

What This Page Covers

This reference page focuses on the SDAP architecture layer: the functional SDAP entity view, SDAP services, expected lower-layer support, and the official SDAP function list. It also highlights how the same architectural model extends across normal NR Uu usage, MBS-related handling, and NR sidelink communication.

SDAP Position in the 5G User Plane Stack

In NR, SDAP sits above PDCP in the user plane and acts as the layer that connects QoS flow handling from upper-layer packet treatment to bearer transport through the radio stack.

Applications / IP / Ethernet SDAP PDCP RLC / MAC / PHY

SDAP Architectural Model

On the transmitting side, an SDAP entity receives SDAP SDUs from upper layers and submits SDAP data PDUs to lower layers. On the receiving side, it receives SDAP data PDUs from lower layers, retrieves the corresponding SDAP SDUs, and delivers them upward.

In the functional architecture view, SDAP performs mapping of QoS flows to DRB, MRB, or SL-DRB, can add or remove the SDAP header depending on bearer configuration, and supports reflective QoS flow to DRB mapping at the UE when downlink SDAP header use is configured.

SDAP architectural flow through one entity
SDAP entity architectural model Upper layers provide SDUs to SDAP, the SDAP entity maps flows, adds or removes headers as needed, and submits PDUs to lower layers. The receiving path reverses the operation. Upper layers SDUs enter or leave SDAP SDAP entity Maps QoS flows to DRB, MRB, or SL-DRB Adds or removes SDAP header when configured Supports reflective QoS flow to DRB mapping where applicable Lower layers PDUs continue through PDCP and below Transmit Receive

SDAP Entity Model

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 Layer-2 ID and cast type in the UE.

On the RRC side, SDAP-Config is typically delivered in RRCReconfiguration as part of bearer configuration, and all configured instances with the same pdu-Session value correspond to the same SDAP entity. In sidelink, the separate SL-SDAP-Config structure is used for the sidelink bearer configuration path.

Functional View of the SDAP Layer

The SDAP functional view includes three main behavior groups:

  • mapping of QoS flows to DRB, MRB, or SL-DRB
  • adding or removing SDAP headers when configured
  • reflective QoS flow to DRB mapping at the UE when applicable

Reflective QoS flow to MRB mapping is not supported, and there is no SDAP header for MRB. For NR sidelink communication, reflective PC5 QoS flow to SL-DRB mapping is not supported.

Services Provided to Upper Layers

The SDAP sublayer provides its service to the user-plane upper layers. The explicit service provided upward by SDAP is transfer of user-plane data.

Services Expected from Lower Layers

SDAP expects user-plane data transfer service from lower layers. It also expects in-order delivery, except when out-of-order delivery is configured by RRC.

Lower-layer assumption

This matters when reading SDAP together with PDCP and RRC, because out-of-order handling is not a generic SDAP choice. It appears as a lower-layer condition shaped by RRC configuration.

Main SDAP Functions

The SDAP sublayer supports the following functions:

  • transfer of user-plane data
  • mapping between a QoS flow and a DRB for both downlink and uplink
  • mapping between an MBS QoS flow and an MRB for downlink
  • mapping between a PC5 QoS flow and an SL-DRB for NR sidelink communication
  • marking QoS flow ID in both downlink and uplink packets
  • marking PC5 QoS flow ID in NR sidelink unicast packets
  • reflective QoS flow to DRB mapping for uplink SDAP data PDUs

Uu, MBS, and Sidelink Architecture Contexts

NR Uu

In standard NR Uu operation, SDAP handles QoS flow to DRB mapping and optional SDAP header processing for PDU-session-based traffic.

MBS

SDAP also includes downlink mapping between an MBS QoS flow and an MRB. MRB handling is part of the SDAP function set, but reflective QoS flow to MRB mapping is not supported and MRB does not use an SDAP header.

NR sidelink

For PC5 communication, SDAP supports mapping between a PC5 QoS flow and an SL-DRB. Over the PC5 interface, the architecture view extends the SDAP entity model beyond ordinary Uu bearer handling into destination-specific and cast-specific sidelink behavior.

How RRC Connects to SDAP Architecture

RRC is what instantiates and configures SDAP behavior in the UE. When SDAP-Config is received, the UE configures the SDAP entity accordingly and associates the DRB with that SDAP entity.

The SDAP-Config IE includes the PDU session identity, downlink and uplink SDAP header presence flags, default DRB indication, and mapped QoS flow add or release lists. For sidelink bearers, SL-SDAP-Config provides the equivalent configurable SDAP parameters.

Key Specification References

Specification Why it matters
3GPP TS 37.324 Primary SDAP architecture, services, and functions specification.
3GPP TS 38.300 NR overall architecture and SDAP sublayer context.
3GPP TS 38.331 RRC configuration model for SDAP entities and DRB association.

Next SDAP Reference Pages

Related Content