5G/6G Implementation Q&A

Q1. What application-level traffic models are supported by NetSim?

The built‑in application/traffic types include Constant Bit Rate (CBR), Voice, Video, Email, Database, FTP, HTTP, and Custom. Each of these models in turn has several options (e.g., Video codecs: H.261, H.263, MPEG1 Low Res, MPEG1 High Res, MPEG2 Low Res, MPEG2 High Res) and configurable parameters.

The transport layer supports UDP and TCP.

Share the traffic patterns that interest you. We can help map them to existing models or advise on customization.

Q2. Which parts of the 5G protocol stack are implemented (UPF, GTP-U, PDCP, RLC, MAC)?

NetSim supports end‑to‑end packet‑level simulation covering the 5G RAN (gNB, UE) and 5G Core (AMF, SMF and UPF).

The RAN stack includes SDAP, PDCP, RLC (TM/UM/AM), MAC and an abstracted PHY. The answers to the next questions cover some of the implementation details.

Q3. Are the protocol implementations provided as open C source code or as library functions?

NetSim includes the C source code for the 5G protocols. Users can modify and extend the implementation.

Q4. Can NetSim be used purely as a framework to test our own proprietary algorithms, rather than using the built-in implementations?

Yes. NetSim has two purposes. It is a ready-to-use 5G/6G simulator with built-in algorithms. It is also a protocol framework for researchers and organizations that want to integrate and validate their own algorithms.

Users can replace NetSim's default implementations for key protocol functionalities including:

• Scheduler (RR, PFS, Max Throughput, or custom)
• Handover decision logic
• Rank Estimation and MU User Pairing
• Link Adaptation and Outer Loop algorithms
• Closed Loop Power Control
• Precoding and beamforming strategies
• Carrier Aggregation policies

The framework provides the underlying protocol stack (SDAP, PDCP, RLC, MAC), traffic generators, radio propagation models, and logging infrastructure. Users can therefore work only on their algorithms, and do not need to rebuild the simulation environment.

Q5. Can we use our own SINR–MCS–BLER curves instead of NetSim's built-in mappings?

Yes. While NetSim includes validated SINR–MCS–BLER curves based on 3GPP standards, the framework supports integration of user-defined curves. This is particularly useful for:

• Proprietary PHY layer implementations
• Custom modulation/coding schemes
• Research on novel link adaptation algorithms
• Validating lab-measured or field-derived performance data

Users can interface their curves through the C source code or through MATLAB/Python integration. This replaces the default PHY abstraction layer and keeps the full protocol stack and simulation infrastructure.

Q6. Is the simulation packet-level, or does it rely on abstract numerical modeling?

NetSim is a packet-level discrete‑event simulator. The packets traverse a virtual TCP/IP stack in every device. Users can log the flow of each packet and the execution of each event. At the PHY, NetSim can record per-slot, per-UE radio measurements (CQI, MCS, SINR and others) when you enable them.

The packets are real: each packet has defined fields, and the protocol operation fills these fields. Only the payload has placeholder data.

NetSim has Wireshark based packet capture in the wired section of the network, but we don’t yet have Wireshark capture capability in the RAN.

Q7. Is the 5G NR PHY explicitly modeled, or is it abstracted?

NetSim models the physical layer through link-to-system abstraction, based on the SINR → CQI → MCS → TBS → BLER mapping. For each UE and carrier, NetSim computes the received SINR by accounting for pathloss, shadowing, fading, antenna gains, transmit power, bandwidth, and interference from neighboring cells/sectors. NetSim maps this SINR to a CQI, which drives MCS selection per the 3GPP spectral efficiency to MCS tables. The selected MCS determines the transport block size (TBS) and PHY rate for a given number of allocated PRBs in each slot.

NetSim evaluates packet decoding success or failure with BLER, which it takes from pre-generated BLER vs SINR curves for each MCS. An in-house link-level simulator generated these curves, and Tetcos validated them against standard references. The SINR-BLER data covers various transport block sizes for all MCSs (1, 2, ..., 28) for Base graphs (1, 2) for all three tables (1, 2, 3). Optional Outer Loop Link Adaptation (OLLA) uses HARQ ACK/NACK feedback to dynamically offset the effective SINR so that the system converges to a target BLER.

When you enable MIMO, NetSim supports configurable gNB and UE transmit/receive antennas. NetSim's rank estimation algorithm determines the number of spatial layers. This abstraction captures the effects of MIMO and beamforming gains on SINR and throughput.

NetSim applies beamforming gains from antenna configuration assumptions. It does not implement explicit PHY signal processing blocks, such as channel estimation, equalization and FFT/IFFT. Instead, SINR, CQI, BLER and HARQ behavior reflect their net effect statistically.

This design choice allows large-scale simulations (thousands of UEs) that would be computationally infeasible with a full baseband PHY.

Q8. If a PHY model is used, are receiver DSP blocks such as channel estimation, equalization, or LLR computation implemented?

NetSim does not model explicit DSP-level receiver blocks such as channel estimation, equalization, or LLR computation. Instead, SINR, CQI, BLER and HARQ behavior capture their aggregate effect statistically, as described in Q7.

Q9. In the absence of explicit PHY processing, how is the SINR–MCS–BLER relationship obtained?

Pre-generated SINR to BLER curves capture the relationship, with one family per MCS. An in-house link-level simulator produced them, and Tetcos validated them against standard references (see Q7). At run time NetSim computes the effective SINR for each code block, then looks up the corresponding BLER for the active MCS to decide code-block success or failure.

The Outer Loop Link Adaptation algorithm can then use HARQ ACK/NACK feedback to step the MCS up or down, so that the system converges to a target BLER. These curves are also reproducible from simulation output: Q10 describes how to extract the SINR to BLER curve for any MCS index directly from the logs. We can discuss the link-level simulator in more detail if there is interest.

Q10. How can I obtain or validate the SINR to BLER curve for a specific MCS index?

NetSim lets you extract the per-MCS BLER against SINR curve directly from the simulation logs. Use this quantity to validate a specific modulation and coding scheme. The PHY operates at the transport-block and code-block level, so the curve is SINR versus Block Error Rate for each MCS index, not an uncoded bit error rate. The SINR on the x-axis is itself an output of the MIMO and fading model, so the two are linked (see Q14).

The procedure is as follows:

• Place one gNB and one UE, each with a single antenna, and use a log-distance pathloss model.
• Set the MCS selection model to the ideal Shannon-based option, enable BLER, and disable OLLA so that the MCS stays fixed.
• Fix the MCS index by editing the AMC table in the LTE_NR source, then rebuild.
• Enable the code block log and the radio measurements log, and configure downlink full-buffer traffic.
• Vary the gNB to UE distance to sweep the SINR across the range of interest, for example -6 dB to 30 dB in 3 dB steps.

For each distance, read the post-association SINR from LTENR_Radio_Measurements_Log.csv (filtered to the PDSCH channel). Read the per-code-block Error or Success outcomes from LTENR_CodeBlock_Log.csv. Then average the instantaneous BLER at each SINR point. A plot of average BLER against SINR gives the curve for that MCS. Repeat for each MCS index to reproduce the full family. A worked example with the plotting scripts and ready-to-run configurations is available on our support portal.

Q11. Are physical-layer reference signals and pilots (CSI-RS, SRS, DM-RS, PRS, etc.) modeled?

No, NetSim does not explicitly model PHY pilots.

However, NetSim deducts the control and pilot overhead when it computes the PRBs available for PUSCH and PDSCH.

Q12. What is the level of PDSCH and PUSCH modeling supported by the simulator?

NetSim models PDSCH and PUSCH at the MAC/transport-block level:

• Slot- and PRB-level scheduling
• SINR-based CQI/MCS selection
• TBS computation using 3GPP tables
• BLER-based decoding
• HARQ with segmentation, retransmissions, and soft combining

Explicit baseband processing (DMRS generation, modulation, scrambling, waveform construction, etc.) and standalone physical control channels (PDCCH/PUCCH) are not modelled individually.

Q13. Which radio propagation models are supported, and are they aligned with 3GPP specifications?

The simulator supports 3GPP TR 38.901 propagation models with standard deployment scenarios such as Rural Macro (RMa), Urban Macro (UMa), Urban Micro (UMi) and Indoor Office environments. For each link, the 3GPP-defined probability models or the user set the LOS/NLOS condition. NetSim models large-scale effects with log-normal shadow fading. You can configure small-scale fading with Rayleigh or Rician models, depending on the scenario and LOS condition.

Q14. What antenna models are available? Can users import custom radiation patterns or configure antenna array geometry?

Users can configure the number of transmit and receive antennas at the gNB and UE to enable MIMO operation. NetSim builds the channel as an Nr x Nt matrix H between the transmit and receive antennas. It supports Rayleigh and Rician fast fading on that matrix through a single Rician K-factor. K = 0 gives Rayleigh, and a large K approaches a constant-gain line-of-sight channel.

On top of this channel you can select the beamforming model:

• Unit gain (no fading): every layer has 0 dB gain. A theoretical baseline, useful for benchmarking.
• Array gain (no fading): array gain of max(Nt, Nr), assuming matched-filter precoding and maximal-ratio combining.
• Eigen (SVD) beamforming, with Rayleigh or Rician fading: the per-layer gains follow from the eigenmodes of the channel matrix, recomputed each coherence time.
• Type-1 codebook, per 3GPP TS 38.214, with Rayleigh or Rician fading: CSI-feedback-based precoding over a configurable N1 x N2 antenna panel with oversampling, selecting the precoder and rank from the standard codebook.

The number of MIMO layers depends on the rank algorithm. With Max Rank, it is fixed at min(Nt, Nr). With the Max Rate algorithm, NetSim selects the layer count that maximises throughput, which can be lower. NetSim writes the per-layer SINR, channel rank, beamforming gain, CQI and MCS to LTENR_Radio_Measurements_Log.csv.

For the antenna radiation pattern, NetSim has built-in Omni and sector antennas based on the 2D parabolic pattern in 3GPP TR 37.840. You can also import custom antenna radiation pattern files for vendor-specific characteristics. NetSim does not model the physical array geometry of NR antenna arrays, such as vertical or horizontal element spacing, element coupling or array layout.

Q15. How is the UE modeled? Does it include a full protocol stack and an explicit PHY implementation?

The UE in NetSim is modelled as follows:

• For uplink transmissions, the UE model accounts for (i) transmit power and antenna gains in the link-budget calculations, (ii) antenna counts and the channel matrix for MIMO-related effects, and (iii) scheduling decisions that are centrally controlled by the gNB.
• For downlink reception, the PHY is abstracted rather than explicitly implemented. The gNB is assumed to have instantaneous and error-free knowledge of the UE’s effective SINR/CQI, which is used to select the MCS based on 3GPP tables. At the UE, packet reception is evaluated using SINR–MCS–BLER curves to determine code-block-group decoding success. When HARQ retransmissions occur, soft combining is modeled at the UE.
• Higher layers of the UE stack (MAC, RLC, PDCP, TCP/UDP, and applications) operate using their respective state machines, consistent with packet-level network simulation.

Q16. Can the simulator interface with external MATLAB, Python, or C/C++ code? Does it support user-defined scheduling, RRM, link adaptation, power control, or beamforming?

Yes. NetSim supports runtime MATLAB interfacing (Engine + socket APIs) and Python socket interfacing.

1. Yes, the scheduler can be customized. The inbuilt support is for RR, PFS and Max Throughput algorithms.
   • For example, we recently added GBR algorithms in our scheduler. This ensures a UE gets a guaranteed rate, if feasible, even when the channel degrades or when the UE moves away.
   • A Python interface passes parameters such as the UE IDs, buffer status, channel state and EWMA throughput to a Python algorithm. The algorithm returns a PRB allocation matrix, and NetSim schedules from that matrix.
2. Yes, link adaptation can be customized. Inner loop link adaptation chooses the MCS per the 3GPP spectral efficiency to MCS tables. An outer loop link adaptation algorithm then steps the MCS up or down to track a BLER that the user sets (such as 5% or 10%).
3. We currently do not have support for Uplink power control.
4. NetSim does not support MU-MIMO today. However, Tetcos developed a Monte-Carlo simulation utility to study MU-MIMO user pairing. It considers antenna counts (1T1R, 2T2R up to 128T128R), angular separation between users, and full or intermittent buffers. It applies different pairing algorithms to evaluate pairing fractions and throughputs at near cell, mid cell and cell edge. We can discuss the MU-MIMO utility in more detail if it interests you.
5. Beamforming can be customized. The available models, from unit gain through the Type-1 codebook, are described in Q14. Eigen beamforming applies SVD precoding along the dominant eigenmodes of the channel matrix H. The per-rank eigenvalues, converted to dB, become the beamforming gains for link-level evaluation. Users can modify the underlying code to implement their own precoding strategy.
6. The Type-1 codebook is now supported, following 3GPP TS 38.214, with CSI-feedback-based precoder and rank selection over a configurable antenna panel (see Q14).

Q17. Does the simulator model PDCCH/PUCCH overhead at the RRM level, and can users define custom control-channel link adaptation?

NetSim does not explicitly model physical control channels such as PDCCH or PUCCH. It captures only their overhead, as a configurable fraction that it deducts in the PDSCH/PUSCH capacity calculations. UL and DL have separate settings, and FR1 and FR2 have different defaults.

There is no RRM-level modeling of PDCCH/PUCCH structures, and user-defined PDCCH-specific link adaptation is not supported.

Q18. How are HARQ and ARQ mechanisms implemented across MAC and higher layers?

NetSim implements HARQ jointly across the MAC and PHY layers, at code block group (CBG) level, with soft combining. NetSim segments each transport block into code blocks and groups them into CBGs. These CBGs go over the air.

NetSim creates a HARQ entity for each gNB–UE pair, separately for uplink and downlink. For each CBG transmission, the receiver returns an ACK or NACK. After a NACK, the transmitter retransmits the CBG, up to a configurable retry limit. NetSim supports multiple parallel HARQ processes (configurable up to 16) for pipelined transmissions. Detailed HARQ logs include code-block outcomes and the SINR after soft combining.

At higher layers, the RLC layer provides ARQ, and RLC-AM supports acknowledged mode retransmissions.

Q19. Does the simulator support intra- and inter-cell handovers, and which RRC events are implemented?

Yes. NetSim supports A3 event handovers and load balancing handovers (with Cell Specific Offset), across sectors and between base stations. Configured measurement criteria and timers drive the handover decisions. NetSim logs each handover event with details such as serving cell, target cell, UE identity, trigger condition and TTT.

A5 event handovers are in development for the next version. Users will then be able to configure A5 handovers for inter-frequency and A3 handovers for intra-frequency.

NetSim implements the essential RRC procedures for handover evaluation and execution:

• Periodic UE measurement reports trigger handover decisions.
• NetSim checks the handover conditions against the configured handover margin and Time-to-Trigger (TTT).
• The serving and target cells exchange Handover Request and Handover ACK messages.
• The serving cell sends the Handover Command to the UE.
• The target cell and the AMF run the path switch procedure, with acknowledgements.
• The AMF and SMF exchange Modify Bearer Request and Response messages.
• The serving and target cells exchange context release and acknowledgement messages.
• The target cell sends the final RRC reconfiguration to the UE.

Q20. Does the simulator support FDD and TDD operation, including carrier aggregation across FR1 and FR2?

NetSim supports both FDD and TDD operation, including carrier aggregation configurations across FR1 and FR2 (intra-band contiguous, intra-band non-contiguous, and inter-band). In carrier aggregation scenarios, the MAC scheduler operates on a per-carrier basis, allowing independent scheduling decisions per component carrier.

Users can develop their own carrier aggregation algorithm at the MAC layer in the protocol C code.

Q21. What logging and tracing capabilities are available? Can slot-level metrics be logged and extended by users?

NetSim provides both generic and technology-specific logging facilities. General traces include Packet Trace and Event Trace for packet-level and protocol-event visibility.

For 5G NR, the simulator generates detailed CSV logs. They cover radio measurements, per-slot resource allocation, handover timers (for example, TTT), and code-block statistics such as HARQ and BLER. These NR traces can log slot-level information for all UEs.

Users can also define new logging parameters. They extend the protocol C code and use NetSim's logging APIs to add custom metrics.

Q22. Does the simulator provide built-in post-processing and visualization of KPIs derived from logs?

Yes. NetSim includes basic post-processing through its built-in results dashboard, which provides standard KPI plots and summary graphs directly from the simulation.

NetSim also generates trace files, log files and measurement outputs in CSV format. Users can post-process this data outside the simulator with Python or similar tools, to make any plot or KPI visualization.

Q23. Which programming languages are used internally, and how can users implement custom equations or models?

The source code is in C. Users can modify the C code directly, or write code in MATLAB or Python and interface it to NetSim.

Q24. What RAN-level metrics and KPIs does NetSim provide for 5G NR?

NetSim captures 65+ metrics across six categories, enabling network performance analysis and integration with external management tools:

• Cell-Level (gNB): PDSCH/PUSCH throughput (Mbps), bytes transmitted (UL/DL)
• Radio Measurements (per-UE): SINR, SNR, Rx Power, CQI (0-15), MCS (0-31), path loss, shadow fading, beamforming gain, interference power, thermal noise
• PRB Allocation: Per-slot PRB allocation per UE, PRB utilization (%), buffer occupancy, MIMO rank
• Network Slicing: Slice ID, slice type (eMBB, URLLC, mMTC), per-slice resource utilization
• Handover: Serving/target cell SSB SNR, handover trigger events with timestamps
• End-to-End: Application throughput, delay (latency), jitter per QoS flow

Q25. What telemetry files does NetSim generate, and at what granularity?

NetSim generates detailed CSV log files suitable for post-processing or integration with external tools:

Slot-level granularity depends on the configured numerology:

• μ=0 (15 kHz SCS): 1 ms slots
• μ=1 (30 kHz SCS): 0.5 ms slots
• μ=2 (60 kHz SCS): 0.25 ms slots
• μ=3 (120 kHz SCS, mmWave): 0.125 ms slots

Q26. Can NetSim integrate with external network management or RAN optimization tools?

Yes. NetSim can serve as a simulated RAN for testing network management algorithms, SON logic, or O-RAN xApps. Integration options include:

1. Batch Processing: Run simulations via CLI and parse generated CSV/XML files programmatically using Python, MATLAB, or other tools.
2. Real-time Streaming: Modify the protocol source code (C) to stream metrics via socket, REST API, or message queue during simulation runtime.
3. Python/MATLAB Interface: Use NetSim's existing external interfaces to extract metrics and forward them to management tools.

This enables use cases such as:

• Generating synthetic RAN data for AI/ML model training
• Testing SON (Self-Organizing Network) algorithms
• Validating O-RAN rApps/xApps against realistic network behavior
• Creating network digital twins for what-if analysis