---
title: 'Simu5G: 5G Simulation Platform'
url: https://www.emergentmind.com/topics/simu5g
type: topic
---

# Simu5G: 5G Simulation Platform

Searching arXiv for recent Simu5G papers and related extensions.
Simu5G is an OMNeT++/INET-based system-level simulator and library for 5G and, in some studies, also 4G/LTE mobile networks. In the literature it is described both as a “system-level 5G library built on OMNeT++/INET” and as an “OMNeT++-based simulator of 5G (NewRadio) and 4G (LTE) mobile networks,” with support for radio-access, core-network, and end-to-end packet transport functions [2401.04626] [2203.13511]. Across published work, Simu5G functions not only as a RAN simulator but as a broader experimental substrate for MEC, vehicular cloud computing, QoS-flow research, TSN bridging, anomaly-data generation, and cyber-security studies [2109.12048] [2311.06938] [2604.04616].

## 1. Core architecture and protocol organization

At its core, Simu5G instantiates user equipment, base-station, and core-network entities as OMNeT++ modules. A representative module inventory includes `NRUE` or `NRUe` for user equipment, `gNB` or `gNodeB` for the 5G base station, and core-network functions such as `AMF`, `SMF`, and `UPF`; some descriptions also list `IptModule` and `EpcApp` as data-plane and control-plane applications [2401.04626]. In end-to-end 5G IoT experiments, Simu5G provided “all of the 3GPP-style gNodeB and core-network modules, the 5G-NR radio stack on the UE, and the 5G-Core control- and user-plane network elements,” including `amf`, `smf`, `upf`, `udm`, `ausf`, `pcf`, `nef`, and `nssf` [2311.06938].

The simulator is organized as a layered protocol stack. A “vanilla” Simu5G node includes an `NrNic` compound NIC with PHY, MAC, RLC, PDCP, and RRC submodules, while INET-based IP/TCP/UDP functionality sits above PDCP [2109.12048]. A global `Binder` stores control-plane state such as UE–gNB associations and RRC contexts and exposes direct API calls to higher-layer modules [2109.12048]. In the calibrated 5G simulator work, this structure is further described as extending or modifying `Phy5G`, `Mac5G`, `Rlc5G`, `Pdcp5G`, `Rrc5G`, `NGCore`, and `Up5G` to realize an end-to-end 5G NR stack with gNB–AMF registration, NG-AP signaling, SMF/UPF path establishment, and user-plane forwarding [2404.10643].

Simu5G’s radio-access behavior is system-level rather than purely abstract. The `gNB` module is reported to contain `NRMac`, `RLC`, `PDCP`, and interfaces toward the 5GC via NG-C and NG-U sockets; it implements beam-forming, scheduling, HARQ, and RRC state machines [2401.04626]. On the UE side, `NRUE` exposes an application layer with sockets for offload clients and server stubs, while its NIC generates uplink and downlink traffic and reacts to handover messages [2401.04626]. This places Simu5G between highly idealized queueing models and hardware testbeds: it represents full protocol chains, but at a granularity suitable for large-scale discrete-event experimentation.

## 2. Configuration, calibration, and scenario construction

A characteristic feature of Simu5G is extensive run-time configuration through `omnetpp.ini` parameters. Published examples tune numerology, bandwidth, carrier frequencies, scheduling policies, handover behavior, and application traffic directly via `*.ini` settings such as `**.ue[*].ueNic.pdschCfg.mcs = 4` or scheduler selection at the gNB [2401.04626]. In a 5G IoT security testbed, the reported software baseline was OMNeT++ 6.0.1, Simu5G 1.2.1, INET 4.5, on Ubuntu 20.04, with a single gNodeB covering 100 `NRUe` devices, default carrier settings such as $f_c = 3.5\,\mathrm{GHz}$ and $BW = 100\,\mathrm{MHz}$, and Simu5G’s built-in proportional-fair MAC scheduler [2311.06938].

The simulator has also been the subject of explicit 3GPP-guided calibration. For 4 GHz urban-macro and rural-macro scenarios, one study calibrated Simu5G against two KPIs, coupling gain and wideband SINR, using
$$
CG[\mathrm{dB}] = P_{TX} - P_{RX},
$$
and
$$
SINR = \frac{P_{RX}}{I + N}.
$$
The authors report that, after tuning parameters such as maximum UE–BS distance, building height, background cells, and thermal noise, the resulting CG and SINR CDFs lay within the 3GPP envelope, with urban CG KS = 0.065, urban SINR KS = 0.138, rural CG KS = 0.089, and rural SINR KS = 0.160 [2404.10643]. The same work documents two implementation fixes: correction of swapped material coefficients in the building-penetration model and a change to the NR band “in use” flag so that it flips only when the BS actually schedules traffic [2404.10643].

The general propagation and link-budget formulations used in Simu5G-based studies are standard. Several papers state path-loss in the form
$$
L(d) = L_0 + 10\cdot n\cdot \log_{10}(d/d_0),
$$
or equivalently
$$
PL(d) = PL(d_0) + 10\cdot n\cdot \log_{10}(d/d_0) + X_\sigma,
$$
while SINR at the receiver is modeled as received signal power over aggregate interference plus noise [2311.06938] [2406.15638]. This does not imply a single mandatory propagation model: published scenarios range from free-space path loss plus log-normal shadowing in a static open-area IoT deployment to 3GPP TR 38.901 rural-macro and urban-macro settings with tuned antenna patterns and fading [2311.06938] [2406.15638] [2404.10643].

To reduce manual scenario engineering, Simu5G has also been coupled to an automation layer. A Python/YAML tool generates `simu5g.ini` and `network_description.ned` from a high-level description parsed by `ScenarioParser`, `BaseStationParser`, `UserParser`, and `BackgroundParser`, allowing users to specify scenario type, base-station positions, X2 links, user counts, interference background, and KPI collection without hand-editing NED or INI files [2404.10643].

## 3. MEC support and real-time emulation

A major branch of Simu5G development concerns ETSI-compliant Multi-access Edge Computing. The MEC-enhanced architecture adds system-level modules such as `UALCMP` and `MecOrchestrator`, and host-level modules such as `MecHost`, `VirtualizationInfrastructureManager (VIM)`, `MecPlatform`, `ServiceRegistry`, `RnisService`, and `LocationService`; dynamically deployed `MecApp` modules are instantiated at run time by the VIM [2109.12048]. In a related framework for rapid MEC prototyping, `UALCMP` terminates the standardized Mx2 RESTful interface toward device apps, while the MEC Platform exposes Mp1 RESTful APIs for service discovery and consumption [2203.13511].

The deployment flow is explicit. A device-side application sends an HTTP POST to `UALCMP`, the orchestrator selects a host based on application requirements, and the chosen VIM instantiates a new `MecApp` module [2109.12048]. In the “WarningAlert” example, only one MEC host advertised `LocationService`; the orchestrator therefore filtered out the other host and placed the application on the eligible one. The reported end-to-end instantiation time was approximately $T_{up} \approx 3\,\mathrm{ms}$, plus a 5 ms orchestrator delay, plus approximately 10 ms VIM start-up, for about 18 ms overall [2109.12048].

Simu5G-based MEC research frequently combines communication and computation models. One framework models internal MEC service contention as an M/M/1 queue with utilization $\rho = (\lambda_f+\lambda_b)/\mu$, while CPU allocation at the host is either segregation-based or fair-sharing [2203.13511]. In a vehicular edge-computing study, each `MecApp` is approximated as an M/M/1 queue with arrival rate $\lambda$ and service rate $\mu = CPU/E[IPR]$, leading to the constraint
$$
P(D_{mec} \le D_{req}) \ge R_{req},
$$
and a minimum CPU allocation
$$
CPU_{min} = \left[\lambda - \frac{\ln(1-R_{req})}{D_{req}}\right]\cdot E[IPR].
$$
The resulting per-service bounds reported in that study were 165,130 MIPS for remote driving, 79,915 MIPS for cooperative sensing, 28,026 MIPS for cooperative maneuver, and 7,992 MIPS for cooperative awareness [2404.05296].

An important practical aspect is real-time emulation. Simu5G integrates OMNeT++’s `RealTimeScheduler` and INET’s `ExtLowerEthernetInterface`, allowing real UE and MEC applications to exchange traffic over virtual Ethernet pairs while the simulated 4G/5G and MEC infrastructure remains in the loop [2109.12048] [2203.13511]. This makes Simu5G useful both for purely synthetic evaluation and for hardware-in-the-loop-style experimentation with external processes.

## 4. QoS flows, SDAP, and deterministic networking

Although Simu5G already provided detailed RAN and core-network abstractions, later work identified a gap in native QoS-flow support. One paper states that, out of the box, Simu5G did not implement the SDAP layer, did not tag packets with QFI, and did not expose per-DRB contexts for scheduling; to address this, the authors added SDAP modules on UE and gNB, per-QFI PDCP and RLC submodules, a `QfiContextManager`, and a new `QosPfScheduler` MAC scheduler [2508.21783]. A parallel SDAP-focused extension inserted `NrTxSdapEntity` and `NrRxSdapEntity` between IP and PDCP, implemented `QosTagReq` and `NrSdapPdu`, and used a configurable `qfiToDrbMap` for logical DRB selection [2508.12785].

The QoS-aware proportional-fair scheduler introduced for smart-factory workloads computes an instantaneous utility
$$
U_i(t)=\alpha_i D_i(t)+\beta_i G_i(t)+\gamma_i P_i(t),
$$
and then a fairness-aware scheduling metric
$$
M_i(t)=\frac{U_i(t)}{\overline{R}_i(t)}.
$$
In the reported six-UE, three-QFI factory scenario, Qos-PF reduced average delay of QFI 1 from approximately 2.7 ms under Max C/I and approximately 2.1 ms under Static Priority to approximately 1.2 ms, achieved QFI 1 deadline-violation ratios of 1.8% versus 5.1% and 21.4%, and obtained Jain’s fairness index above 0.90 versus approximately 0.57 for Max C/I and approximately 0.75 for Static Priority [2508.21783].

The SDAP multiplexing extension is narrower in scope but establishes packet-level QoS tagging and header processing. It reports successful validation for QFI extraction, SDAP header insertion and removal, QFI-to-DRB logical mapping, and end-to-end packet integrity; in the stable-channel, no-handover setup of that paper, packet loss was zero both with and without SDAP [2508.12785]. The same study reports mean latencies of 18.3 ms without SDAP and 11.9, 13.2, 15.0, and 12.1 ms for QFIs 1, 5, 9, and 63 with SDAP in the tested configuration [2508.12785].

Simu5G has also been extended into a 5G-TSN bridge. The nascTime framework, built on OMNeT++ 6.3, INET 4.6, and Simu5G v1.4.1-sdap-2, realizes NW-TT and DS-TT modules, a full PCP $\rightarrow$ DSCP $\rightarrow$ QFI $\rightarrow$ SDAP/DRB pipeline, and IEEE 802.1AS transparent-clock behavior with measured residence time [2604.04616]. In the ideal-channel scenario, high-priority traffic achieved 99.9% delivery with mean end-to-end delay 2.58 ms, while measured 5GS residence-time variance was below $0.2\,\mu s$; under fading, residence-time variance increased to $48\,\mu s$ or, in the tabulated statistics, 48.2 $\mu s$ [2604.04616]. This suggests that Simu5G’s full PHY–MAC–RLC–PDCP/SDAP chain can capture timing jitter that abstract-delay models do not represent.

## 5. Data generation, vertical applications, and empirical studies

Simu5G is widely used as a controlled data generator for downstream ML and systems research. In a 5G IoT cyber-security study, authors built an end-to-end OMNeT++/INET+Simu5G testbed with 100 simulated IoT devices, a single gNodeB, and three rogue hosts generating a UDP flood. Packet traces were captured through OMNeT++’s signal mechanism, annotated via `Ipv4NetworkConfigurator`, and exported as CSV with 16 features per event, yielding approximately 512,666 total samples: 256,354 benign and 256,312 attack [2311.06938]. The resulting CNN and FNN classifiers each reached 99% accuracy, and the reported DDoS condition caused near-100% loss and extreme queueing delays [2311.06938].

A second data-centric use is anomaly detection and root-cause analysis in 5G RANs. Using a calibrated seven-gNodeB, single-tier hexagonal deployment at 4 GHz and 10 MHz bandwidth, with Random Waypoint mobility and full-buffer traffic, one study injected two fault classes—Excessive Power Reduction and Inter-cell Interference—and logged per-cell KPIs every second [2406.15638]. The published dataset contains 50,400 labeled node-seconds from two load regimes, while UE-level raw logs amount to approximately 3 million records [2406.15638]. These traces supported the “Simba” pipeline, which combines Graph Neural Networks with a Transformer for spatio-temporal anomaly detection and root-cause analysis [2406.15638].

Vehicular and edge-cloud studies illustrate another usage mode: Simu5G as a compositional systems simulator. An ETSI MEC-compliant vehicular cloud extension added a Broker, `Car` modules derived from `NRUE`, `ClientResApp`, `VIApp`, and MEC-host orchestration components. In the reported experiments, resource-acquisition join time increased from 13 ms for 10 vehicles to 40 ms for 100 vehicles, release time remained about 7–7.5 ms, and even with 300 simultaneous app-instantiation requests, per-request allocation stayed below 40 ms [2401.04626]. In connected and automated vehicle scenarios, Simu5G was integrated with Veins and SUMO over a 1 km² Paris district; the study found that slower CPUs supported remote driving and cooperative sensing at 100% success only up to two vehicles, while cooperative maneuver remained feasible up to 10 vehicles and cooperative awareness up to 20 vehicles under the reported conditions [2404.05296]. A later vehicular edge-computing platform, VecSim, placed Simu5G gNBs and UEs within an OMNeT++ framework that additionally modeled RSU servers, SRS-driven offloading control, and Scheduler–RSU RPCs [2512.14002].

Taken together, these studies suggest that Simu5G is used as a reproducible experiment engine for generating labels, KPIs, and control traces under explicitly modeled 5G radio and core-network conditions, rather than solely as a throughput or latency calculator.

## 6. Assumptions, limitations, and research position

The literature repeatedly emphasizes that Simu5G scenarios depend strongly on configuration choices and extension maturity. Some studies use highly simplified setups: the 5G IoT DDoS testbed fixed all UEs in place, used default PHY settings, modeled only free-space path loss plus log-normal shadowing, and limited the traffic mix to ICMP and a single high-rate UDP flood, with no radio-link metrics such as RSRP or CQI in the dataset [2311.06938]. MEC-service abstractions in rapid-prototyping work assume Poisson arrivals, exponential service times, the PASTA property, and approximate GPS for CPU sharing [2203.13511]. ETSI reference-point coverage is also incomplete in that framework; the paper explicitly notes that not all interfaces, such as Mm-Xm or federated multi-orchestrator scenarios, are modeled [2203.13511].

A second limitation concerns native feature coverage. Before the SDAP-related extensions, published work characterized Simu5G as lacking SDAP and per-QFI modeling, which constrained realistic QoS-flow simulation [2508.21783] [2508.12785]. The existence of multiple extension lines—MEC, vehicular cloud, calibrated anomaly generation, SDAP/QFI support, TSN translators—shows both the flexibility of the platform and the fact that advanced use cases often require nontrivial augmentation.

A common misconception is that Simu5G is only a radio-access simulator. The published record shows otherwise: it has been used for end-to-end 5G core modeling, ETSI-compliant MEC orchestration, real-time emulation with external applications, vehicular cloud resource management, QoS-flow scheduling, TSN bridge timing analysis, and ML dataset generation [2109.12048] [2203.13511] [2401.04626] [2604.04616]. The corresponding caution is that realism is not automatic. Calibration against 3GPP envelopes, explicit propagation choices, scenario-specific mobility and traffic models, and, where necessary, custom protocol extensions are central to credible use of Simu5G in research [2404.10643] [2406.15638].

In that sense, Simu5G occupies a specific methodological position. It is neither a black-box network emulator nor merely a narrow PHY model. It is a modular OMNeT++/INET-based 5G experimentation substrate whose research value derives from configurable protocol stacks, inspectable state, reproducible event traces, and a growing body of domain-specific extensions.

Source: https://www.emergentmind.com/topics/simu5g