5G-LENA nr-v3.0-32-g83aee33
The 5G/NR module for the ns-3 simulator
Loading...
Searching...
No Matches
test Directory Reference

Files

 nr-antenna-3gpp-model-conf.cc
 
 nr-lte-cc-bwp-configuration.cc
 The 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-pattern-generation.cc
 The 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-short-bsr-ce-test.cc
 
 nr-phy-patterns.cc
 The 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-power-allocation.cc
 
 nr-realistic-beamforming-test.cc
 This 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-spectrum-phy-test.cc
 
 nr-spectrum-phy-test.h
 
 nr-system-test-configurations.cc
 Test the configuration for 5G-LENA. Test that does nothing at the moment.
 
 nr-system-test-schedulers-ofdma-mr.cc
 System test for OFDMA - Max rate scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-system-test-schedulers-ofdma-pf.cc
 System test for OFDMA - Proportional Fair scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-system-test-schedulers-ofdma-rr.cc
 System test for OFDMA - Round Robin scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-system-test-schedulers-tdma-mr.cc
 System test for TDMA - Max Rate scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-system-test-schedulers-tdma-pf.cc
 System test for TDMA - Proportional Fair scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-system-test-schedulers-tdma-rr.cc
 System test for TDMA - Round Robin scheduler. It checks that all the packets sent are delivered correctly.
 
 nr-test-fdm-of-numerologies.cc
 This 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.cc
 System-testing for effective SINR computation for HARQ Incremental Redundancy (IR) and Chase Combining (CC).
 
 nr-test-l2sm-eesm.cc
 This 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.cc
 This 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.cc
 In 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.cc
 The 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-uplink-power-control-test.cc
 
 system-scheduler-test-qos.cc
 
 system-scheduler-test-qos.h
 This test case checks if the throughput obtained is as expected for the QoS scheduling logic.
 
 system-scheduler-test.cc
 
 system-scheduler-test.h
 This 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.