openairinterface5G issueshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues2017-08-29T16:52:26Zhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/10Throughput drops to 02017-08-29T16:52:26ZGhost UserThroughput drops to 0From SYRTEM : In "--phy-test" mode, RX throughput drops to 0 (no more data traffic) on UE side. It does not happen regularly, as well after 25minutes as after 5hours. Note : After UE re-start, throughput stays unchanged from its last val...From SYRTEM : In "--phy-test" mode, RX throughput drops to 0 (no more data traffic) on UE side. It does not happen regularly, as well after 25minutes as after 5hours. Note : After UE re-start, throughput stays unchanged from its last value. After eNodeB re-start (and also UE re-start), throughput comes back to its maximum value.UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/9Throughput not stable at MCS282017-08-29T16:52:26ZGhost UserThroughput not stable at MCS28From SYRTEM : Throughput is not stable at MCS28 (BW 5MHz) in "--phy-test" mode.From SYRTEM : Throughput is not stable at MCS28 (BW 5MHz) in "--phy-test" mode.UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/8RACH preamble decoding error detected on eNodeB2018-02-08T16:27:22ZGhost UserRACH preamble decoding error detected on eNodeBFrom SYRTEM: In "--calib-prach-tx" mode (BW 5MHz), Preamble decoding by eNodeB is not the expected one (preamble=19) after 5 minutes to 20 minutes. eNodeB send synchronization signals in BCCH. UE shall decode them and send RACH preamble...From SYRTEM: In "--calib-prach-tx" mode (BW 5MHz), Preamble decoding by eNodeB is not the expected one (preamble=19) after 5 minutes to 20 minutes. eNodeB send synchronization signals in BCCH. UE shall decode them and send RACH preamble. When experiment fails, preamble continuously increases or decreases when decoded on the eNodeB side.UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/7UE is removed by eNodeB because ULSCH consecutive error count is reached2017-08-29T16:52:26ZGhost UserUE is removed by eNodeB because ULSCH consecutive error count is reachedFrom SYRTEM : In "noS1" mode (BW 5MHz), UE is removed by eNodeB after 1 minute to 30 minutes because ULSCH consecutive error count is reached (eNodeB is running with "--ulsch-max-errors 10" in our tests).From SYRTEM : In "noS1" mode (BW 5MHz), UE is removed by eNodeB after 1 minute to 30 minutes because ULSCH consecutive error count is reached (eNodeB is running with "--ulsch-max-errors 10" in our tests).UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/6Iperf results not stable between 2 consecutive runs2018-02-08T16:27:22ZGhost UserIperf results not stable between 2 consecutive runsFrom SYRTEM :
Iperf results are not stable between 2 consecutive runs. BW 5MHz MCS19 iperf with UDP packets 2Mbps from eNodeB to UE
test 1 : about 2Mbps received on UE.
test 2 : about 1Mbps received on UE.From SYRTEM :
Iperf results are not stable between 2 consecutive runs. BW 5MHz MCS19 iperf with UDP packets 2Mbps from eNodeB to UE
test 1 : about 2Mbps received on UE.
test 2 : about 1Mbps received on UE.UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/5Exit on "resource type 1 not supported for N_RB_DL=100"2017-08-29T16:52:26ZGhost UserExit on "resource type 1 not supported for N_RB_DL=100"From SYRTEM: In "--phy-test" mode (BW 10MHz), UE exists on "[conv_rballoc] resource type 1 not supported for N_RB_DL=100" (ie. N_RB_DL=50).From SYRTEM: In "--phy-test" mode (BW 10MHz), UE exists on "[conv_rballoc] resource type 1 not supported for N_RB_DL=100" (ie. N_RB_DL=50).UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/4BW 10MHz No RRC connection2018-02-08T16:27:22ZGhost UserBW 10MHz No RRC connectionFrom SYRTEM: In "noS1" mode (BW 10MHz), No RRC connection could be established.From SYRTEM: In "noS1" mode (BW 10MHz), No RRC connection could be established.UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/3Real-Time scheduling - UE Thread maximum period until 15,1ms2017-08-29T16:52:26ZGhost UserReal-Time scheduling - UE Thread maximum period until 15,1msFrom F. Robinet, SYRTEM: The "UE_thread" period, that shall be 1ms, could reach 15,1ms. Note : lte-softmodem application can not capture error above 10ms of delay in reason of modulo implementation .From F. Robinet, SYRTEM: The "UE_thread" period, that shall be 1ms, could reach 15,1ms. Note : lte-softmodem application can not capture error above 10ms of delay in reason of modulo implementation .UE Robustnesshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/2Real-Time scheduling - RX Thread not scheduled / scheduled late2018-02-08T16:27:22ZGhost UserReal-Time scheduling - RX Thread not scheduled / scheduled lateON behalf of Fabrice Robinet, SYRTEM: The "UE_thread_rx" period, that shall be 1ms, could reach 4,95ms. In VCD capture, "UE_thread_tx" is scheduled and "UE_thread_rx" is not, while both signal conditions are met.ON behalf of Fabrice Robinet, SYRTEM: The "UE_thread_rx" period, that shall be 1ms, could reach 4,95ms. In VCD capture, "UE_thread_tx" is scheduled and "UE_thread_rx" is not, while both signal conditions are met.UE Robustness