SDAP Extension: Enhancing Simu5G QoS Simulation

Updated 8 July 2026

SDAP Extension for Simu5G is a modular add-on that integrates a native SDAP layer between IP and PDCP to enable precise QoS flow handling.
It employs configurable QFI-to-DRB mapping and logical flow differentiation to simulate multi-QFI scenarios and support differentiated traffic classes.
Validation demonstrates reduced latency and jitter, confirming that the extension effectively enriches 5G NR simulation fidelity according to 3GPP standards.

Searching arXiv for the cited Simu5G/SDAP papers to ground the article in current sources. The SDAP Extension for Simu5G denotes a modular, standardscompliant addition to the OMNeT++-based Simu5G simulator that introduces native support for QoS Flow multiplexing and QFI-aware bearer handling in the 5G NR user plane (Seliem et al., 18 Aug 2025). In 3GPP 5G NR, the Service Data Adaptation Protocol (SDAP) is the layer that sits between the IP layer and PDCP, and its purpose is to bind IP packets to QoS Flows and map those flows onto Data Radio Bearers (DRBs) (Seliem et al., 18 Aug 2025). The extension therefore addresses a structural modeling gap in pre-extension Simu5G, where packets moved from IP straight to PDCP with no QFI tagging, no SDAP header processing, and no real representation of QoS Flows, so all traffic was effectively handled through a simplified bearer model inherited from LTE (Seliem et al., 18 Aug 2025). The resulting capability is intended for multi-QFI simulation scenarios, differentiated QoS flows, flowaware scheduling policies, per-flow isolation, latency-sensitive traffic, and industrial QoS profiles (Seliem et al., 18 Aug 2025).

1. Modeling gap and motivation

Before the extension, Simu5G already modeled much of the NR stack, but it lacked SDAP entirely, so packets moved from IP straight to PDCP with no QFI tagging, no SDAP header processing, and no real representation of QoS Flows (Seliem et al., 18 Aug 2025). That meant all traffic was effectively handled through a simplified bearer model inherited from LTE, which is not sufficient for studies that need fine-grained QoS behavior, flow isolation, or multi-flow bearer mapping (Seliem et al., 18 Aug 2025).

The stated motivation is that Simu5G’s default stack was missing the 5G-specific flow adaptation layer introduced by 3GPP (Seliem et al., 18 Aug 2025). Without SDAP, researchers could not accurately model multiple QoS Flows per UE, QFI-based flow classification, flow-to-bearer multiplexing, differentiated handling of traffic classes, and control-plane-driven bearer selection logic (Seliem et al., 18 Aug 2025). The paper explicitly frames this as a structural modeling gap, particularly limiting for simulations of latency-sensitive applications, industrial communication, or scenarios where different flows on the same UE must be isolated or scheduled differently (Seliem et al., 18 Aug 2025).

In standards terms, the design is anchored in 3GPP TS 38.331 and TS 38.413, and also discusses 3GPP TS 23.501 and TS 38.401 for the broader QoS and architecture context (Seliem et al., 18 Aug 2025). In 5G NR, SDAP is the protocol responsible for QoS Flow adaptation in the user plane; each flow is identified by a QFI, and multiple QFIs may be mapped to one DRB, or one flow may be placed on a dedicated DRB depending on policy and service requirements (Seliem et al., 18 Aug 2025). The paper emphasizes that this mechanism is a key 5G feature absent in LTE, where bearer-based mapping dominated and 5G decouples QoS flows from bearers more explicitly (Seliem et al., 18 Aug 2025).

2. Placement in the Simu5G stack

The extension adds SDAP as a new layer between IP and PDCP on both the UE and gNB side, mirroring the 3GPP user-plane architecture (Seliem et al., 18 Aug 2025). The architecture introduces two OMNeT++ modules: NrTxSdapEntity for transmit-side processing and NrRxSdapEntity for receive-side processing (Seliem et al., 18 Aug 2025).

The protocol-stack placement is specified as follows (Seliem et al., 18 Aug 2025):

On transmit: IP → SDAP → PDCP → RLC → MAC → PHY
On receive: PHY → MAC → RLC → PDCP → SDAP → IP

This placement is important because SDAP is supposed to operate above PDCP, and the implementation does so without modifying PDCP, RLC, or MAC internals (Seliem et al., 18 Aug 2025). The paper characterizes this as non-intrusive and backward-compatible with existing Simu5G LTE-inspired components (Seliem et al., 18 Aug 2025). The transmit SDAP entity takes packets from the IP/application side, extracts the QFI, inserts the SDAP header, and forwards the packet to PDCP; the receive SDAP entity performs the reverse operation by receiving a packet from PDCP, removing the SDAP header, extracting the QFI, and forwarding the packet upward to IP (Seliem et al., 18 Aug 2025).

A broader Simu5G extension methodology is visible in related work on MEC integration, which describes Simu5G as organized with UE/gNB communication via the NR protocol stack inside NrNic, upper layers from INET, and extension through modular compound modules and submodules, NED/INI configuration, and OMNeT++ gates/messages (Noferi et al., 2021). This suggests architectural continuity between the SDAP extension and other Simu5G subsystem integrations.

3. SDAP data structures and packet processing

The SDAP header, as described in the paper, is lightweight and contains three fields: QFI, a 6-bit QoS Flow Identifier; D/C bit, indicating data vs. control; and RQI, the Reflective QoS Indicator (Seliem et al., 18 Aug 2025). The implementation uses a dedicated message/chunk type called NrSdapPdu to represent the SDAP header (Seliem et al., 18 Aug 2025).

Because Simu5G does not implement full control-plane signaling for dynamic QFI assignment, the implementation uses a lightweight simulation-friendly mechanism based on OMNeT++/INET packet tags (Seliem et al., 18 Aug 2025). A custom tag called QosTagReq is attached to packets at the application layer and carries the desired QFI value (Seliem et al., 18 Aug 2025). The application can specify the QFI through the OMNeT++ .ini file, and if no tag is present, the SDAP module falls back to a default QFI of zero, preserving compatibility with existing applications (Seliem et al., 18 Aug 2025).

On transmit, NrTxSdapEntity reads the QosTagReq tag, extracts the QFI, and uses it to create the SDAP header (Seliem et al., 18 Aug 2025). The transmit operation is described step by step as follows (Seliem et al., 18 Aug 2025):

reads the QFI from QosTagReq,
removes/extracts the outer IPv4 and transport headers,
creates an NrSdapPdu,
sets the QFI field,
sets the D/C bit to data mode,
sets RQI to false by default,
inserts the SDAP header at the front of the packet,
restores the transport and IP headers,
updates length fields as needed,
forwards the packet to PDCP.

The receive side performs the symmetrical operation (Seliem et al., 18 Aug 2025):

extracts the outer IP header,
determines whether the transport header is UDP or TCP,
extracts the transport header,
removes the SDAP header,
reads the embedded QFI,
looks up the logical DRB,
reattaches transport and IP headers,
forwards the packet upward.

A key point in the design is that the SDAP header is inserted at the correct protocol boundary between IP and PDCP, which is what the standards require (Seliem et al., 18 Aug 2025). The paper stresses that the transport and IP headers are temporarily removed and then reinserted to preserve correct positioning of the SDAP PDU (Seliem et al., 18 Aug 2025). The logical flow path is therefore: application tags packet with QosTagReq, TX SDAP reads QFI, TX SDAP inserts NrSdapPdu, lower layers transport packet, RX SDAP extracts NrSdapPdu, and RX SDAP recovers QFI (Seliem et al., 18 Aug 2025).

4. Configurable QFI-to-DRB mapping and multi-QFI operation

The extension adds a configurable logical mapping from QFIs to DRBs (Seliem et al., 18 Aug 2025). This mapping is not full physical DRB multiplexing yet; instead, it is a logical mapping table used to simulate bearer-selection decisions and enable traceable flow differentiation (Seliem et al., 18 Aug 2025). The mapping is specified through an .ini parameter called qfiToDrbMapping, and during module initialization, the string is parsed into an internal map in both SDAP entities (Seliem et al., 18 Aug 2025).

The paper gives the following example mapping (Seliem et al., 18 Aug 2025):

QFI 1 → DRB 0
QFI 5 → DRB 1
QFI 9 → DRB 2
QFI 63 → DRB 3

When a packet arrives at the transmit SDAP module, the QFI is looked up in this table and the selected DRB is logged; the same mapping is used on the receiver for symmetry and validation (Seliem et al., 18 Aug 2025). If a QFI is not found, DRB 0 is used as the default (Seliem et al., 18 Aug 2025). This gives researchers control over how flows are grouped without requiring deep changes in lower layers (Seliem et al., 18 Aug 2025).

A major contribution of the extension is support for multi-QFI scenarios (Seliem et al., 18 Aug 2025). Different applications can be assigned different QFIs through configuration, and the SDAP layer will preserve and process those flow identities separately, enabling multiple flows from the same UE to be treated as distinct QoS flows rather than being merged into a single generic bearer model (Seliem et al., 18 Aug 2025). In the evaluation, the authors assign QFIs 1, 5, 9, and 63 to four UDP CBR applications, and each flow is then mapped to a different DRB logically (Seliem et al., 18 Aug 2025). Even though the underlying PDCP/RLC/MAC stack is still shared physically, the SDAP layer logs and preserves the distinction between flows, which is enough to study flow-aware behavior at the simulation level (Seliem et al., 18 Aug 2025).

The paper identifies the main added or modified components as NrTxSdapEntity, NrRxSdapEntity, NrSdapPdu message definition, QosTag / QosTagReq message definition, and modified NED files for UE and gNB protocol stack composition (Seliem et al., 18 Aug 2025). Packet metadata is handled through INET’s tagging infrastructure, and header serialization uses INET’s chunk-based packet model, allowing the SDAP logic to remain isolated from PDCP/RLC/MAC internals (Seliem et al., 18 Aug 2025).

5. Validation and reported performance

The validation has two parts: functional correctness and QoS differentiation (Seliem et al., 18 Aug 2025). For functional validation, the authors perform packet-level tracing and logging to confirm that QFI extraction from QosTagReq works, SDAP header insertion is correct, QFI-to-DRB lookup works, SDAP header removal on reception works, the same QFI/DRB mapping is observed end-to-end, packet integrity is preserved, and no mismatches, corruption, or packet loss occur because of SDAP processing (Seliem et al., 18 Aug 2025). The validation table lists these checkpoints, all marked as passed (Seliem et al., 18 Aug 2025).

The debug outputs shown in the paper include the following examples (Seliem et al., 18 Aug 2025):

[TX] QFI = 5 extracted from QosTagReq;
[TX] Inserted SDAP header with QFI = 5;
[TX] Selected DRB = 1 for QFI = 5.
[RX] Extracted QFI = 5
[RX] Mapped DRB = 1

These logs confirm that the transmit and receive paths behave symmetrically and that the mapping is consistent (Seliem et al., 18 Aug 2025).

For QoS differentiation evaluation, the simulated scenario is a single-cell standalone 5G NR deployment with one gNB, one stationary UE, 50 resource blocks, 40 dBm gNB power, 26 dBm UE power, no mobility, no fading, and 20-second simulation time (Seliem et al., 18 Aug 2025). Multiple UDP CBR traffic sources run at 50 packets per second and 160-byte packets, representative of VoIP-like traffic, and each flow gets a different QFI (Seliem et al., 18 Aug 2025).

The reported mean latency and standard deviation are (Seliem et al., 18 Aug 2025):

Without SDAP: 18.3 ms mean, 4.5 ms std dev
With SDAP:
- QFI 1: 11.9 ms, 1.4 ms
- QFI 5: 13.2 ms, 1.7 ms
- QFI 9: 15.0 ms, 2.0 ms
- QFI 63: 12.1 ms, 1.5 ms

The interpretation given in the paper is that SDAP-based separation reduces latency and jitter, because flow isolation reduces cross-flow interference (Seliem et al., 18 Aug 2025). The paper treats this as evidence that the extension can support differentiated QoS behavior in a way the baseline Simu5G model could not (Seliem et al., 18 Aug 2025). This suggests that the logical QFI-to-DRB separation, even without full physical DRB multiplexing, is sufficient to expose per-flow behavior at the simulation level.

6. Relation to other Simu5G extensions and to 5G-TSN QoS mapping

The SDAP extension sits within a broader pattern of Simu5G extensibility. The MEC work describes an ETSI-compliant MEC model implemented on top of Simu5G, adding a MEC system-level layer, a MEC host-level layer, RESTful APIs, and dynamic creation and deletion of MEC app modules (Noferi et al., 2021). It does not describe SDAP, NR bearer mapping, QoS flow mapping, or packet header handling in the 5G stack, but it is valuable as a Simu5G extension methodology reference because it shows how new modeled functionality can be added through new modules, interfaces, direct method calls, gates/messages, and NED/INI-driven configuration (Noferi et al., 2021). In this respect, the SDAP extension follows an established Simu5G integration style: modular encapsulation, minimal intrusion into existing stack internals, and configuration-driven operation.

A more directly related development appears in nascTime, a full-stack 5G-TSN bridge simulation framework built on OMNeT++ 6.3, INET 4.6, and Simu5G that implements the full 3GPP Release 16 TSN bridge model with SDAP-based QoS flow multiplexing and per-flow DRB selection (Seliem et al., 6 Apr 2026). That framework explicitly describes the complete QoS chain as PCP → DSCP → QFI → SDAP/DRB → MAC scheduling → DSCP → PCP (Seliem et al., 6 Apr 2026). The paper states that the SDAP layer was originally contributed by the authors to Simu5G v1.4.1, to support per-flow QoS differentiation through DRB selection (Seliem et al., 6 Apr 2026).

In nascTime, SDAP uses the QFI to select a specific Data Radio Bearer (DRB), with the example configuration DRB 0: QFI [0] and DRB 1: QFI [6], and the MAC scheduler can then differentiate flows structurally because they are separated into different DRBs (Seliem et al., 6 Apr 2026). The paper also highlights a Simu5G-specific requirement for multi-UE SDAP/DRB mapping: multiSession=true must be set on the PDCP and RLC submodules of Simu5G’s NRNicEnbDrb module (Seliem et al., 6 Apr 2026). This clarifies that the SDAP extension is not limited to single-flow toy scenarios; it also serves as the basis for multi-endpoint bridge operation with per-flow QoS treatment (Seliem et al., 6 Apr 2026).

Validation in nascTime further reports a 1.16 ms mean-delay difference between High-priority traffic on DRB 1 and Best-effort traffic on DRB 0, which the paper explicitly interprets as evidence of QoS differentiation created by SDAP-based DRB selection (Seliem et al., 6 Apr 2026). This does not alter the Simu5G SDAP extension itself, but it places that extension within a more elaborate architecture where TSN priority semantics are preserved across the full chain PCP → DSCP → QFI → SDAP → DRB → MAC (Seliem et al., 6 Apr 2026).

7. Significance, scope, and limitations

The main practical value of the SDAP extension is that it makes Simu5G useful for research that depends on 5G NR QoS Flow semantics (Seliem et al., 18 Aug 2025). The paper specifically identifies latency-sensitive applications such as VoIP or industrial control, URLLC-like traffic separation, eMBB/mMTC coexistence experiments, per-flow scheduling and resource allocation, QoS-aware bearer mapping, flow isolation and interference effects, and future work on SDAP-aware MAC scheduling as enabled research directions (Seliem et al., 18 Aug 2025).

At the same time, the implementation scope is explicitly bounded. The QFI-to-DRB relation is described as a logical mapping, not full physical DRB multiplexing yet (Seliem et al., 18 Aug 2025). Simu5G also does not implement full control-plane signaling for dynamic QFI assignment, so the design uses the QosTagReq mechanism as a lightweight simulation-friendly alternative (Seliem et al., 18 Aug 2025). The paper presents this not as a full lower-layer redesign, but as a clean insertion of SDAP between IP and PDCP with QFI tagging and logical DRB mapping, sufficient to unlock a broad set of studies on 5G QoS behavior while keeping Simu5G’s existing architecture intact (Seliem et al., 18 Aug 2025).

The authors indicate several directions for more advanced extensions: physical DRB multiplexing, dynamic control-plane QFI assignment, reflective QoS indicator support, control PDU support, and integration with QoS-aware schedulers (Seliem et al., 18 Aug 2025). A plausible implication is that the current extension functions as an enabling substrate rather than a terminal model of all SDAP features. Within that scope, the paper’s overall significance is summarized as turning Simu5G from a bearer-centric 5G simulator into one that can represent the core 5G NR QoS Flow abstraction in a way that is modular, standards-compliant, backward-compatible, configurable via .ini, and suitable for multi-flow simulation experiments (Seliem et al., 18 Aug 2025).