5G-LENA  nr-v3.0-25-g90be5d1
The 5G/NR module for the ns-3 simulator
File List
Here is a list of all documented files with brief descriptions:
 bandwidth-part-gnb.cc
 bandwidth-part-gnb.h
 bandwidth-part-ue.cc
 bandwidth-part-ue.h
 beam-id.cc
 beam-id.h
 beam-manager.cc
 beam-manager.h
 beamforming-algorithm.cc
 beamforming-algorithm.h
 beamforming-helper-base.cc
 beamforming-helper-base.h
 beamforming-vector.cc
 beamforming-vector.h
 bwp-manager-algorithm.cc
 bwp-manager-algorithm.h
 bwp-manager-gnb.cc
 bwp-manager-gnb.h
 bwp-manager-ue.cc
 bwp-manager-ue.h
 cc-bwp-helper.cc
 cc-bwp-helper.h
 cttc-3gpp-channel-example.ccChannel Example
 cttc-3gpp-channel-nums-fdm.ccFrequency division multiplexing example, with TDD and FDD
 cttc-3gpp-channel-nums.ccSimple topology numerologies example
 cttc-3gpp-channel-simple-fdm.ccSimple frequency division multiplexing example
 cttc-3gpp-channel-simple-ran.ccSimple RAN
 cttc-3gpp-indoor-calibration.ccSimulation script for the NR-MIMO Phase 1 system-level calibration
 cttc-channel-randomness.cc
 cttc-error-model-amc.ccError model example with adaptive modulation and coding: 1 gNB and 1 UE, multiple packets with non-varying fading conditions
 cttc-error-model-comparison.ccError model example comparison: TBS for all MCSs
 cttc-error-model.ccError model example with fixed MCS: 1 gNB and 1 UE, multiple packets with varying fading conditions
 cttc-fh-compression.ccA multi-cell network deployment with site sectorization
 cttc-lte-ca-demo.ccExample for setting LTE CA scenario
 cttc-nr-3gpp-calibration-user.ccA multi-cell network deployment with site sectorization
 cttc-nr-3gpp-calibration-utils-v1.cc
 cttc-nr-3gpp-calibration-utils-v1.h
 cttc-nr-3gpp-calibration-utils-v2.cc
 cttc-nr-3gpp-calibration-utils-v2.h
 cttc-nr-3gpp-calibration.cc
 cttc-nr-3gpp-calibration.h
 cttc-nr-cc-bwp-demo.ccCreates a NR TDD deployment with a configurable number of sites, UEs, downlink and uplink flows
 cttc-nr-demo.ccA cozy, simple, NR demo (in a tutorial style)
 cttc-nr-mimo-demo.ccAn example that shows how to setup and use MIMO
 cttc-nr-multi-flow-qos-sched.ccThis example allows testing the performance of the QoS scheduler (nr-mac-scheduler-ofdma/tdma-qos) in conjunction with the LC QoS scheduler versus other schedulers, such as the RR and PF in conjunction with the LC RR scheduler. The example has been designed to test the E2E delay and throughput in a single-cell scenario with 2 UEs, where 1 UE has a NON-GBR flow and the other UE has 2 flows. One NON-GBR flow, and 1 DC-GBR with its gbr requirements set (erabGuaranteedBitRate)
 cttc-nr-notching.ccCreates a configurable NR TDD/FDD deployment with up to 2 gNBs, for testing a notching mask
 cttc-nr-simple-qos-sched.ccA simple example for QoS scheduler (nr-mac-scheduler-ofdma/tdma-qos)
 cttc-nr-traffic-3gpp-xr.ccSimple topology consisting of 1 GNB and various UEs. Can be configured with different 3GPP XR traffic generators (by using XR traffic mixer helper)
 cttc-nr-traffic-ngmn-mixed.ccA hegagonal topology example used to show how to configure different NGMN types of traffics or NGMN mixed scenario
 cttc-realistic-beamforming.cc
 file-scenario-helper.cc
 file-scenario-helper.h
 3gpp-outdoor-calibration/flow-monitor-output-stats.cc
 lena-lte-comparison/flow-monitor-output-stats.cc
 3gpp-outdoor-calibration/flow-monitor-output-stats.h
 lena-lte-comparison/flow-monitor-output-stats.h
 grid-scenario-helper.cc
 grid-scenario-helper.h
 groups.h
 hexagonal-grid-scenario-helper.cc
 hexagonal-grid-scenario-helper.h
 ideal-beamforming-algorithm.cc
 ideal-beamforming-algorithm.h
 ideal-beamforming-helper.cc
 ideal-beamforming-helper.h
 introspected-doxygen.hAutomatic doxygen for TypeIds Doxygen docs generated from the TypeId database
 lena-error-model.cc
 lena-error-model.h
 lena-lte-comparison-campaign.cc
 lena-lte-comparison-user.ccA multi-cell network deployment with site sectorization
 lena-lte-comparison.cc
 lena-lte-comparison.h
 lena-v1-utils.cc
 lena-v1-utils.h
 lena-v2-utils.cc
 lena-v2-utils.h
 node-distribution-scenario-interface.cc
 node-distribution-scenario-interface.h
 nr-amc.cc
 nr-amc.h
 nr-antenna-3gpp-model-conf.cc
 nr-bearer-stats-calculator.cc
 nr-bearer-stats-calculator.h
 nr-bearer-stats-connector.cc
 nr-bearer-stats-connector.h
 nr-bearer-stats-simple.cc
 nr-bearer-stats-simple.h
 nr-cb-two-port.cc
 nr-cb-two-port.h
 nr-cb-type-one.cc
 nr-cb-type-one.h
 nr-ch-access-manager.cc
 nr-ch-access-manager.h
 nr-control-messages.cc
 nr-control-messages.h
 nr-eesm-cc-t1.cc
 nr-eesm-cc-t1.h
 nr-eesm-cc-t2.cc
 nr-eesm-cc-t2.h
 nr-eesm-cc.cc
 nr-eesm-cc.h
 nr-eesm-error-model.cc
 nr-eesm-error-model.h
 nr-eesm-ir-t1.cc
 nr-eesm-ir-t1.h
 nr-eesm-ir-t2.cc
 nr-eesm-ir-t2.h
 nr-eesm-ir.cc
 nr-eesm-ir.h
 nr-eesm-t1.cc
 nr-eesm-t1.h
 nr-eesm-t2.cc
 nr-eesm-t2.h
 nr-error-model.cc
 nr-error-model.h
 nr-gnb-mac.cc
 nr-gnb-mac.h
 nr-gnb-net-device.cc
 nr-gnb-net-device.h
 nr-gnb-phy.cc
 nr-gnb-phy.h
 nr-harq-phy.cc
 nr-harq-phy.h
 nr-helper.cc
 nr-helper.h
 nr-interference.cc
 nr-interference.h
 nr-lte-cc-bwp-configuration.ccThe test aims at proving that the creation of operation bands, component carriers (CC) and bandwidth parts (BWP) is correct within the limitations of the NR implementation. The main limitation of BWPs is that they do not overlap, because in such case, the interference calculation would be erroneous. This test also proves that the creation of BWP information with the CcBwpHelper is correct
 nr-lte-mi-error-model.cc
 nr-lte-mi-error-model.h
 nr-lte-pattern-generation.ccThe test considers the function NrGnbPhy::GenerateStructuresFromPattern and checks that the output of that function is equal to the one pre-defined. Test includes also the Harq feedback indication
 nr-mac-csched-sap.h
 nr-mac-harq-process.h
 nr-mac-harq-vector.cc
 nr-mac-harq-vector.h
 nr-mac-header-fs-dl.cc
 nr-mac-header-fs-dl.h
 nr-mac-header-fs-ul.cc
 nr-mac-header-fs-ul.h
 nr-mac-header-fs.cc
 nr-mac-header-fs.h
 nr-mac-header-vs-dl.cc
 nr-mac-header-vs-dl.h
 nr-mac-header-vs-ul.cc
 nr-mac-header-vs-ul.h
 nr-mac-header-vs.cc
 nr-mac-header-vs.h
 nr-mac-pdu-info.h
 nr-mac-rx-trace.cc
 nr-mac-rx-trace.h
 nr-mac-sched-sap.cc
 nr-mac-sched-sap.h
 nr-mac-scheduler-cqi-management.cc
 nr-mac-scheduler-cqi-management.h
 nr-mac-scheduler-harq-rr.cc
 nr-mac-scheduler-harq-rr.h
 nr-mac-scheduler-lc-alg.cc
 nr-mac-scheduler-lc-alg.h
 nr-mac-scheduler-lc-qos.cc
 nr-mac-scheduler-lc-qos.h
 nr-mac-scheduler-lc-rr.cc
 nr-mac-scheduler-lc-rr.h
 nr-mac-scheduler-lcg.cc
 nr-mac-scheduler-lcg.h
 nr-mac-scheduler-ns3.cc
 nr-mac-scheduler-ns3.h
 nr-mac-scheduler-ofdma-mr.cc
 nr-mac-scheduler-ofdma-mr.h
 nr-mac-scheduler-ofdma-pf.cc
 nr-mac-scheduler-ofdma-pf.h
 nr-mac-scheduler-ofdma-qos.cc
 nr-mac-scheduler-ofdma-qos.h
 nr-mac-scheduler-ofdma-rr.cc
 nr-mac-scheduler-ofdma-rr.h
 nr-mac-scheduler-ofdma.cc
 nr-mac-scheduler-ofdma.h
 nr-mac-scheduler-srs-default.cc
 nr-mac-scheduler-srs-default.h
 nr-mac-scheduler-srs.h
 nr-mac-scheduler-tdma-mr.cc
 nr-mac-scheduler-tdma-mr.h
 nr-mac-scheduler-tdma-pf.cc
 nr-mac-scheduler-tdma-pf.h
 nr-mac-scheduler-tdma-qos.cc
 nr-mac-scheduler-tdma-qos.h
 nr-mac-scheduler-tdma-rr.cc
 nr-mac-scheduler-tdma-rr.h
 nr-mac-scheduler-tdma.cc
 nr-mac-scheduler-tdma.h
 nr-mac-scheduler-ue-info-mr.h
 nr-mac-scheduler-ue-info-pf.cc
 nr-mac-scheduler-ue-info-pf.h
 nr-mac-scheduler-ue-info-qos.cc
 nr-mac-scheduler-ue-info-qos.h
 nr-mac-scheduler-ue-info-rr.h
 nr-mac-scheduler-ue-info.cc
 nr-mac-scheduler-ue-info.h
 nr-mac-scheduler.cc
 nr-mac-scheduler.h
 nr-mac-scheduling-stats.cc
 nr-mac-scheduling-stats.h
 nr-mac-short-bsr-ce-test.cc
 nr-mac-short-bsr-ce.cc
 nr-mac-short-bsr-ce.h
 nr-mimo-chunk-processor.cc
 nr-mimo-chunk-processor.h
 nr-mimo-matrices-eigen.cc
 nr-mimo-matrices-no-eigen.cc
 nr-mimo-matrices.cc
 nr-mimo-matrices.h
 nr-mimo-signal.cc
 nr-mimo-signal.h
 nr-net-device.cc
 nr-net-device.h
 nr-phy-mac-common.cc
 nr-phy-mac-common.h
 nr-phy-patterns.ccThe test creates a fake MAC that checks if, when PHY calls the DL/UL slot allocations, it does it for the right slot in pattern. In other words, if the PHY calls the UL slot allocation for a slot that should be DL, the test will fail
 nr-phy-rx-trace.cc
 nr-phy-rx-trace.h
 nr-phy-sap.cc
 nr-phy-sap.h
 nr-phy.cc
 nr-phy.h
 nr-pm-search-full.cc
 nr-pm-search-full.h
 nr-pm-search.cc
 nr-pm-search.h
 nr-point-to-point-epc-helper.cc
 nr-point-to-point-epc-helper.h
 nr-power-allocation.cc
 nr-radio-bearer-tag.cc
 nr-radio-bearer-tag.h
 nr-radio-environment-map-helper.cc
 nr-radio-environment-map-helper.h
 nr-realistic-beamforming-test.ccThis test tests how different levels of received SINR SRS affect the realistic beamforming algorithm performance. What is expected is that when SINR is high that realistic beamforming algorithm will select the same beamforming vector pair as it would ideal beamforming algorithm that has the perfect knowledge of the channel. On the other hand, when SINR is low it is expected that the error in estimation of the channel is high, thus the selected beamforming pair is expected to be different from those that are selected by the ideal beamforming algorithm. Note that as the ideal and realistic beamforming algorithms are not exactly the same, i.e., ideal beamforming algorithm assumes perfect knowledge of the full channel (including long-term component of the fading, the Doppler, and frequency-selectivity) while realistic beamforming algorithm only estimates the long-term component of the fading. Hence, then slight variations on the best beam selection may appear
 nr-rrc-protocol-ideal.cc
 nr-rrc-protocol-ideal.h
 nr-spectrum-phy-test.cc
 nr-spectrum-phy-test.h
 nr-spectrum-phy.cc
 nr-spectrum-phy.h
 nr-spectrum-signal-parameters.cc
 nr-spectrum-signal-parameters.h
 nr-spectrum-value-helper.cc
 nr-spectrum-value-helper.h
 nr-stats-calculator.cc
 nr-stats-calculator.h
 nr-system-test-configurations.ccTest the configuration for 5G-LENA. Test that does nothing at the moment
 nr-system-test-schedulers-ofdma-mr.ccSystem test for OFDMA - Max rate scheduler. It checks that all the packets sent are delivered correctly
 nr-system-test-schedulers-ofdma-pf.ccSystem test for OFDMA - Proportional Fair scheduler. It checks that all the packets sent are delivered correctly
 nr-system-test-schedulers-ofdma-rr.ccSystem test for OFDMA - Round Robin scheduler. It checks that all the packets sent are delivered correctly
 nr-system-test-schedulers-tdma-mr.ccSystem test for TDMA - Max Rate scheduler. It checks that all the packets sent are delivered correctly
 nr-system-test-schedulers-tdma-pf.ccSystem test for TDMA - Proportional Fair scheduler. It checks that all the packets sent are delivered correctly
 nr-system-test-schedulers-tdma-rr.ccSystem test for TDMA - Round Robin scheduler. It checks that all the packets sent are delivered correctly
 nr-test-fdm-of-numerologies.ccThis test case checks if the throughput achieved over certain bandwidth part is proportional to the bandwidth of that bandwidth part. The test scenario consists of a scenario in which two UEs are attached to a gNB, and perform UDP full buffer downlink traffic. gNB is configured to have 2 bandwidth parts, which are configured with the same numerology, but can have different bandwidth. Bandwidth part manager is configured to forward first flow over the first bandwidth part, and the second flow over the second bandwidth part. Since the traffic is full buffer traffic, it is expected that when more bandwidth is provided, more throughput will be achieved and vice versa
 nr-test-harq.ccSystem-testing for effective SINR computation for HARQ Incremental Redundancy (IR) and Chase Combining (CC)
 nr-test-l2sm-eesm.ccThis test validates specific functions of the NR PHY abstraction model. The test checks two issues: 1) LDPC base graph (BG) selection works properly, and 2) BLER values are properly obtained from the BLER-SINR look up tables for different block sizes, MCS Tables, BG types, and SINR values
 nr-test-notching.ccThis test is used to validate the notching functionality. In order to do so, it creates a fake MAC and checks in the method TestNotchingGnbMac::DoSchedConfigIndication() that RBG mask is in the DCI is constructed in accordance with the (tested) notching mask
 nr-test-numerology-delay.ccIn this test case we want to observe delays of a single UDP packet, and to track its eNB processing time, air time, UE time depending on the numerology
 nr-test-sched.ccThe class is a stub for a future, unit-testing component for the various kind of schedulers. The idea is to check what is happening to the scheduling part following a black-box approach: passing inputs, and then see what is the output, and if it is like we would expect. The reference API is the FF API, and we should check what happens, for example, when adding or removing users, when a CQI is passed, etc
 nr-test-sfnsf.cc
 nr-test-timings.cc
 nr-ue-mac.cc
 nr-ue-mac.h
 nr-ue-net-device.cc
 nr-ue-net-device.h
 nr-ue-phy.cc
 nr-ue-phy.h
 nr-ue-power-control.cc
 nr-ue-power-control.h
 nr-uplink-power-control-test.cc
 3gpp-outdoor-calibration/power-output-stats.cc
 lena-lte-comparison/power-output-stats.cc
 3gpp-outdoor-calibration/power-output-stats.h
 lena-lte-comparison/power-output-stats.h
 3gpp-outdoor-calibration/rb-output-stats.cc
 lena-lte-comparison/rb-output-stats.cc
 3gpp-outdoor-calibration/rb-output-stats.h
 lena-lte-comparison/rb-output-stats.h
 realistic-beamforming-algorithm.cc
 realistic-beamforming-algorithm.h
 realistic-beamforming-helper.cc
 realistic-beamforming-helper.h
 realistic-bf-manager.cc
 realistic-bf-manager.h
 rem-beam-example.ccRem beam configuration example
 rem-example.ccREM Creation Example
 scenario-parameters.cc
 scenario-parameters.h
 sfnsf.cc
 sfnsf.h
 3gpp-outdoor-calibration/sinr-output-stats.cc
 lena-lte-comparison/sinr-output-stats.cc
 3gpp-outdoor-calibration/sinr-output-stats.h
 lena-lte-comparison/sinr-output-stats.h
 3gpp-outdoor-calibration/slot-output-stats.cc
 lena-lte-comparison/slot-output-stats.cc
 3gpp-outdoor-calibration/slot-output-stats.h
 lena-lte-comparison/slot-output-stats.h
 system-scheduler-test-qos.cc
 system-scheduler-test-qos.hThis test case checks if the throughput obtained is as expected for the QoS scheduling logic
 system-scheduler-test.cc
 system-scheduler-test.hThis test case checks if the throughput obtained per UE is as expected for the specified scheduling logic. The test scenario consists of a scenario in which various UEs are attached to a single gNB. UEs transmit a fixed amount of packets, at a certain rate, and the test checks that all the packets are delivered correctly. gNB is configured to have 1 bandwidth part. UEs can belong to the same or different beams. This examples uses beam search beamforming method
 three-gpp-ftp-m1-helper.cc
 three-gpp-ftp-m1-helper.h
 traffic-generator-3gpp-audio-data.cc
 traffic-generator-3gpp-audio-data.h
 traffic-generator-3gpp-generic-video.cc
 traffic-generator-3gpp-generic-video.h
 traffic-generator-3gpp-pose-control.cc
 traffic-generator-3gpp-pose-control.h
 traffic-generator-example.cc
 traffic-generator-ftp-single.cc
 traffic-generator-ftp-single.h
 traffic-generator-helper.cc
 traffic-generator-helper.h
 traffic-generator-ngmn-ftp-multi.cc
 traffic-generator-ngmn-ftp-multi.h
 traffic-generator-ngmn-gaming.cc
 traffic-generator-ngmn-gaming.h
 traffic-generator-ngmn-video.cc
 traffic-generator-ngmn-video.h
 traffic-generator-ngmn-voip.cc
 traffic-generator-ngmn-voip.h
 traffic-generator-test.cc
 traffic-generator-test.h
 traffic-generator.ccTraffic generator example
 traffic-generator.h
 xr-traffic-mixer-helper.cc
 xr-traffic-mixer-helper.h