---
title: 'SDAP Extension: Enhancing Simu5G QoS Simulation'
url: https://www.emergentmind.com/topics/sdap-extension-for-simu5g
type: topic
---

# SDAP Extension: Enhancing Simu5G QoS Simulation

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 [2508.12785]. 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) [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

## 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 [2508.12785]. 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 [2508.12785].

The stated motivation is that Simu5G’s default stack was missing the 5G-specific flow adaptation layer introduced by 3GPP [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

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 [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

## 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 [2508.12785]. The architecture introduces two OMNeT++ modules: **NrTxSdapEntity** for transmit-side processing and **NrRxSdapEntity** for receive-side processing [2508.12785].

The protocol-stack placement is specified as follows [2508.12785]:

- **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 [2508.12785]. The paper characterizes this as non-intrusive and backward-compatible with existing Simu5G LTE-inspired components [2508.12785]. 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 [2508.12785].

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 [2109.12048]. 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 [2508.12785]. The implementation uses a dedicated message/chunk type called **NrSdapPdu** to represent the SDAP header [2508.12785].

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 [2508.12785]. A custom tag called **QosTagReq** is attached to packets at the application layer and carries the desired QFI value [2508.12785]. 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 [2508.12785].

On transmit, **NrTxSdapEntity** reads the `QosTagReq` tag, extracts the QFI, and uses it to create the SDAP header [2508.12785]. The transmit operation is described step by step as follows [2508.12785]:

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

The receive side performs the symmetrical operation [2508.12785]:

1. extracts the outer IP header,
2. determines whether the transport header is UDP or TCP,
3. extracts the transport header,
4. removes the SDAP header,
5. reads the embedded QFI,
6. looks up the logical DRB,
7. reattaches transport and IP headers,
8. 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 [2508.12785]. The paper stresses that the transport and IP headers are temporarily removed and then reinserted to preserve correct positioning of the SDAP PDU [2508.12785]. 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 [2508.12785].

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

The extension adds a configurable logical mapping from QFIs to DRBs [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

The paper gives the following example mapping [2508.12785]:

- **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 [2508.12785]. If a QFI is not found, DRB 0 is used as the default [2508.12785]. This gives researchers control over how flows are grouped without requiring deep changes in lower layers [2508.12785].

A major contribution of the extension is support for **multi-QFI scenarios** [2508.12785]. 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 [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

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 [2508.12785]. 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 [2508.12785].

## 5. Validation and reported performance

The validation has two parts: **functional correctness** and **QoS differentiation** [2508.12785]. 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 [2508.12785]. The validation table lists these checkpoints, all marked as passed [2508.12785].

The debug outputs shown in the paper include the following examples [2508.12785]:

```text
[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 [2508.12785].

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** [2508.12785]. 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 [2508.12785].

The reported mean latency and standard deviation are [2508.12785]:

- **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 [2508.12785]. The paper treats this as evidence that the extension can support differentiated QoS behavior in a way the baseline Simu5G model could not [2508.12785]. 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 [2109.12048]. 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 [2109.12048]. 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** [2604.04616]. That framework explicitly describes the complete QoS chain as **PCP → DSCP → QFI → SDAP/DRB → MAC scheduling → DSCP → PCP** [2604.04616]. 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** [2604.04616].

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 [2604.04616]. 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 [2604.04616]. 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 [2604.04616].

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** [2604.04616]. 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** [2604.04616].

## 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 [2508.12785]. 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 [2508.12785].

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 [2508.12785]. 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 [2508.12785]. 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 [2508.12785].

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** [2508.12785]. 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** [2508.12785].

Source: https://www.emergentmind.com/topics/sdap-extension-for-simu5g