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.

We have support for both UDP and TCP in the transport layer.

Users can share the traffic patterns of interest, 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).

RAN stack includes SDAP, PDCP, RLC (TM/UM/AM), MAC, and an abstracted PHY. Some of the implementation details are covered in the answers to the subsequent questions

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

The source C source code for the 5G protocols is included in NetSim. 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 is designed to serve dual purposes: (1) as a ready-to-use 5G/6G simulator with built-in algorithms, and (2) as a flexible protocol framework for researchers and organizations who wish 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—allowing users to focus solely on their algorithm development without rebuilding the entire 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 via MATLAB/Python integration, enabling seamless replacement of the default PHY abstraction layer while retaining 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 per‑slot per-UE radio measurements (CQI, MCS, SINR etc) can be recorded when enabled.

The packets are real in the sense that various fields are defined for the packets, and these fields are populated by the protocol operation. The payload alone 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?

The physical layer is modeled through link-to-system abstraction mechanisms centered around 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. This SINR is then mapped to a CQI, which drives MCS selection per 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.

Packet decoding success or failure is evaluated using BLER, which is obtained from pre-generated BLER vs SINR curves for each MCS. These curves have been generated using an in-house link-level simulator and validated 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 MIMO is enabled, NetSim supports configurable gNB and UE transmit/receive antennas, with the number of spatial layers determined by NetSim’s rank estimation algorithm. This abstraction captures the effects of MIMO and beamforming gains on SINR and throughput.

Beamforming gains are applied based on antenna configuration assumptions, but explicit PHY signal processing blocks - such as channel estimation, equalization, FFT/IFFT, etc., - are not implemented. Instead, their net effect is reflected statistically through SINR, CQI, BLER, and HARQ behavior.

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, their aggregate effect is captured statistically through SINR, CQI, BLER, and HARQ behavior as described in A5.

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

Yes. BLER is looked up from proprietary BLER‑MCS‑SINR curves as explained in Q5. We can discuss the link level simulator in more detail if there is interest.

NetSim supports an Outer loop link adaptation algorithm that uses HARQ ACK/NACK to step-up/step-down the MCS in order to converge to a target BLER.

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

No, NetSim does not explicitly model PHY pilots.

However, control/pilot overhead is accounted for when computing PRBs available for PUSCH and PDSCH.

Q11. 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.

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

The simulator supports 3GPP TR 38.900 propagation models with standard deployment scenarios such as Rural Macro (RMa), Urban Macro (UMa), Urban Micro (UMi) and Indoor Office environments. For each link, LOS/NLOS conditions are determined either using 3GPP-defined probability models or explicitly configured by the user. Large-scale effects are modeled using log-normal shadow fading, while small-scale fading can be configured using Rayleigh or Rician models depending on the scenario and LOS condition.

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

A13. Users can configure the number of transmission and receive antennas at the gNB and UE to enable MIMO operations. The effective number of MIMO layers is determined by a Rank algorithm whose inputs are configured antenna counts. The number of spatial layers and the beamforming gains would impact throughput.

NetSim has in-built support for Omni and sector antennas based on the 2D parabolic antenna pattern given in 3GPP TR 37.840. NetSim also provides an option to import custom antenna radiation pattern files, allowing users to model vendor-specific antenna characteristics.

Beamforming effects are incorporated as aggregate gain assumptions rather than explicit per-element signal processing.

NetSim does not explicitly model antenna array geometry, and parameters such as vertical or horizontal element spacing, element coupling, or array layout are not considered for NR antenna arrays.

Q14. 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.

Q15. 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.
   • We also have a python interface using which parameters such as the UE ID's, buffer status, channel state, and EWMA throughput, can be passed as input to a python algorithm which can then return a PRB allocation matrix based on which NetSim can do the scheduling operation.
2. Yes, Link adaptation can be customized. We currently have inner loop link adaptation whereby MCS is chosen per the 3GPP spectral efficiency to MCS tables. Subsequently we have an outer loop link adaptation algorithm which bumps up/down the MCS to track a user input BLER (such as 5% or 10%).
3. We currently do not have support for Uplink power control.
4. We currently do not have support for MU-MIMO within NetSim. However, we recently developed a Monte-Carlo simulation utility for studying MU-MIMO user pairing. It considers Antenna counts (1T1R, 2T2R …. 128T128R), Angular separation between users, Full buffer vs. Intermittent buffer, etc., and applies different pairing algorithms to evaluate pairing fractions and throughputs at near cell, mid cell and cell edge. We can discuss MU-MIMO utility in more detail if there is interest.
5. NetSim supports SVD (Eigen) beamforming by default. An H matrix is generated based on user-selected Rayleigh or Rician fast fading model. SVD (Eigen) precoding is applied by aligning transmission along the dominant eigenmodes of H. The resulting eigenvalues represent the precoding/beamforming gains per spatial rank, which are converted to dB and used for link-level performance evaluation. Users can modify the underlying code to implement their custom beamforming.
6. Type-1 code book is under development and is expected in the next version.

Q16. 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. Only impact captured is (a configurable) overhead fraction that is deducted during PDSCH/PUSCH capacity calculations, with separate settings for UL and DL and different defaults for FR1 and FR2.

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

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

HARQ in NetSim is implemented jointly across the MAC and PHY layers, at a code block group (CBG) level and supports soft combining. In NetSim, each transport block is segmented into code blocks, which are then grouped into CBGs. These CBGs are sent over the air.

A HARQ entity is instantiated per gNB–UE pair, separately for uplink and downlink. For each CBG transmission, the receiver returns an ACK or NACK; upon NACK, the transmitter retransmits the corresponding CBG up to a configurable retry limit. Multiple parallel HARQ processes are supported (configurable up to 16), enabling pipelined transmissions. Detailed HARQ-related logging is available, including code-block outcomes and the SINR post–soft-combining.

At higher layers, ARQ functionality is provided by the RLC layer, with RLC-AM supporting acknowledged mode retransmissions.

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

Yes. NetSim supports A3 event as well as load balancing handovers (using Cell Specific Offset) across sectors as well as between base stations, with handover decisions driven by configured measurement criteria and timers. Handover events are logged with details such as serving cell, target cell, UE identity, trigger condition, and TTT.

A5 event handovers are currently under development and is expected in the next version. Then users can configure A5 handovers for inter-frequency and A3 handovers for intra-frequency.

NetSim implements the essential RRC procedures required for handover evaluation and execution. This includes periodic UE measurement reporting that triggers handover decisions, validation of handover conditions based on the configured handover margin and Time-to-Trigger (TTT), and execution of the handover through the exchange of control signaling. The handover execution involves Handover Request and Handover ACK messages exchanged between the serving and target cells, the transmission of the Handover Command from the serving cell to the UE, and subsequent path switch procedures with corresponding acknowledgements between the target cell and the AMF. In addition, NetSim models Modify Bearer Request and Response signaling between the AMF and SMF, followed by context release and acknowledgement messages between the serving and target cells, and final RRC reconfiguration from the target cell to the UE.

Q19. 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.

A user-defined carrier aggregation algorithm can be developed at the MAC layer by modifying the protocol C code.

Q20. 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 covering radio measurements, per-slot resource allocation, handover-related timers (e.g., TTT), and code-block-level statistics such as HARQ and BLER. Slot-level information can be logged for all UEs as part of these NR-specific traces.

Additionally, users can define new logging parameters by extending the protocol C code and using NetSim’s logging APIs to instrument custom metrics.

Q21. 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.

In addition, NetSim generates a rich set of trace files, log files, and measurement outputs in CSV format. Given the breadth and granularity of this data, users also perform advanced post-processing outside the simulator - very easily using Python (or similar tools) - to generate any plot or KPI visualization of their choice.

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

The source codes are written in C. Users can directly modify the C code or write code in MATLAB or Python and interface that to NetSim.