Simu5G: 5G Simulation Platform

• Simu5G is a system-level simulator that models 5G and 4G/LTE networks using modular OMNeT++/INET components for realistic radio and core network simulation.
• It employs a layered protocol stack and calibration techniques to accurately emulate RAN, QoS-flow, SDAP, and TSN bridging scenarios.
• The platform supports MEC integration, real-time emulation, and data generation for security, anomaly detection, and vehicular cloud applications.

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 (Feraudo et al., 2024, Noferi et al., 2022). 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 (Noferi et al., 2021, Alzhrani et al., 2023, Seliem et al., 6 Apr 2026).

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 (Feraudo et al., 2024). 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 (Alzhrani et al., 2023).

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 (Noferi et al., 2021). A global Binder stores control-plane state such as UE–gNB associations and RRC contexts and exposes direct API calls to higher-layer modules (Noferi et al., 2021). 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 (Boeira et al., 2024).

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 (Feraudo et al., 2024). 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 (Feraudo et al., 2024). 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 (Feraudo et al., 2024). 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 (Alzhrani et al., 2023).

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 (Boeira et al., 2024). 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 (Boeira et al., 2024).

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 (Alzhrani et al., 2023, Hasan et al., 2024). 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 (Alzhrani et al., 2023, Hasan et al., 2024, Boeira et al., 2024).

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 (Boeira et al., 2024).

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](https://www.emergentmind.com/topics/vision-mamba-vim)), MecPlatform, ServiceRegistry, RnisService, and LocationService; dynamically deployed MecApp modules are instantiated at run time by the VIM (Noferi et al., 2021). 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 (Noferi et al., 2022).

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 (Noferi et al., 2021). 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 (Noferi et al., 2021).

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 (Noferi et al., 2022). 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

$BW = 100\,\mathrm{MHz}$0

and a minimum CPU allocation

$BW = 100\,\mathrm{MHz}$1

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 (Ouedraogo et al., 2024).

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 (Noferi et al., 2021, Noferi et al., 2022). 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 (Seliem et al., 29 Aug 2025). 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 (Seliem et al., 18 Aug 2025).

The QoS-aware proportional-fair scheduler introduced for smart-factory workloads computes an instantaneous utility

$BW = 100\,\mathrm{MHz}$2

and then a fairness-aware scheduling metric

$BW = 100\,\mathrm{MHz}$3

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 (Seliem et al., 29 Aug 2025).

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 (Seliem et al., 18 Aug 2025). 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 (Seliem et al., 18 Aug 2025).

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 $BW = 100\,\mathrm{MHz}$4 DSCP $BW = 100\,\mathrm{MHz}$5 QFI $BW = 100\,\mathrm{MHz}$6 SDAP/DRB pipeline, and IEEE 802.1AS transparent-clock behavior with measured residence time (Seliem et al., 6 Apr 2026). 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 $BW = 100\,\mathrm{MHz}$7; under fading, residence-time variance increased to $BW = 100\,\mathrm{MHz}$8 or, in the tabulated statistics, 48.2 $BW = 100\,\mathrm{MHz}$9 (Seliem et al., 6 Apr 2026). 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 (Alzhrani et al., 2023). The resulting CNN and FNN classifiers each reached 99% accuracy, and the reported DDoS condition caused near-100% loss and extreme queueing delays (Alzhrani et al., 2023).

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 (Hasan et al., 2024). The published dataset contains 50,400 labeled node-seconds from two load regimes, while UE-level raw logs amount to approximately 3 million records (Hasan et al., 2024). These traces supported the “Simba” pipeline, which combines Graph Neural Networks with a Transformer for spatio-temporal anomaly detection and root-cause analysis (Hasan et al., 2024).

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 (Feraudo et al., 2024). 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 (Ouedraogo et al., 2024). 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 (Gao et al., 16 Dec 2025).

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 (Alzhrani et al., 2023). MEC-service abstractions in rapid-prototyping work assume Poisson arrivals, exponential service times, the PASTA property, and approximate GPS for CPU sharing (Noferi et al., 2022). 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 (Noferi et al., 2022).

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 (Seliem et al., 29 Aug 2025, Seliem et al., 18 Aug 2025). 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 (Noferi et al., 2021, Noferi et al., 2022, Feraudo et al., 2024, Seliem et al., 6 Apr 2026). 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 (Boeira et al., 2024, Hasan et al., 2024).

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.