openairinterface5G issueshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues2017-08-04T14:15:45Zhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/47UE: NAS and PDCP UE fixes for Com4Innov tests2017-08-04T14:15:45ZGhost UserUE: NAS and PDCP UE fixes for Com4Innov testsSeveral issues blocking Attach procedure and data transfer were found in NAS UE part during tests with Com4Innov:
- eNB requested IMEISV, but UE do not answer it
- ksi computation was wrong if ksi is different f...Several issues blocking Attach procedure and data transfer were found in NAS UE part during tests with Com4Innov:
- eNB requested IMEISV, but UE do not answer it
- ksi computation was wrong if ksi is different from 0
- emergency NAS was not supported
- S1: PDCP not receiving/transmitting data to network interface
Investigation by Eurecom and TCLBug UE L3+BilelBilelhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/46UE: L2 UL MAC Assert "RLC has segmented more data than BO stored in MAC"2017-09-15T11:49:35ZGhost UserUE: L2 UL MAC Assert "RLC has segmented more data than BO stored in MAC"Assert found in noS1 and S1 with Com4Innov
Current UE implementation assumes that UL RLC Buffer Occupancy given to MAC is including RLC header (this is not 3GPP compliant but acceptable, will fix later).
But for RLC UM, RLC always send t...Assert found in noS1 and S1 with Com4Innov
Current UE implementation assumes that UL RLC Buffer Occupancy given to MAC is including RLC header (this is not 3GPP compliant but acceptable, will fix later).
But for RLC UM, RLC always send total SDU size + 2 bytes of header (in SN10 bits, 1 byte for SN5 bits) to MAC.
If UE receives higher layer data to Tx and has no PUSCH, it triggers a BSR, then a SR. If the UE receives more data until it gets granted, then the BO increase but with an erroneous RLC PDU header information. When MAC multiplex data, the assert can then occur.
Fix consists in adding variable LI part to the BO according to the number of stored SDUs in RLC.
The code changes are restricted to UE for the moment, to be checked with eNB according to eNB MAC schedulerBug UE L2https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/45UE: add PRACH, BCH and RAR to wireshark logging2017-08-04T14:15:45ZWilsonUE: add PRACH, BCH and RAR to wireshark loggingAlso fixed incorrect frame / subframe numbering in uplink and downlink logs
Need wireshark v2.2.2 to read/parse the PRACH, BCH and RAR logsAlso fixed incorrect frame / subframe numbering in uplink and downlink logs
Need wireshark v2.2.2 to read/parse the PRACH, BCH and RAR logsEnhancement UE LayerXWilsonWilsonhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/44TDD UE: UE crashes when sending msg32017-08-04T14:15:45ZWilsonTDD UE: UE crashes when sending msg3fix: call phy_procedures_UE_S_TX() instead of phy_procedures_UE_TX() when it is a special subframe, then the issue is avoidedfix: call phy_procedures_UE_S_TX() instead of phy_procedures_UE_TX() when it is a special subframe, then the issue is avoidedBug UE L2WilsonWilsonhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/43TDD UE: PRACH timing advance is not set to 624 in TDD mode2017-08-04T14:15:45ZWilsonTDD UE: PRACH timing advance is not set to 624 in TDD modeIt causes eNB to detect the PRACH with incorrect preamble index and reply to UE with the wrong preamble index in msg2. UE attachment cannot proceed.It causes eNB to detect the PRACH with incorrect preamble index and reply to UE with the wrong preamble index in msg2. UE attachment cannot proceed.Bug UE L1WilsonWilsonhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/42TDD UE: SIBs information not detected in TDD mode2017-08-04T14:15:45ZWilsonTDD UE: SIBs information not detected in TDD modeAfter PCI and PBCH detected, UE does not detect any SI-RNTI DCIs. No SIBs information is received and cannot proceed attaching.
branch = develop1B
commit = 85361335e5098
date = Fri Nov 18 13:33:13 2016 -0800After PCI and PBCH detected, UE does not detect any SI-RNTI DCIs. No SIBs information is received and cannot proceed attaching.
branch = develop1B
commit = 85361335e5098
date = Fri Nov 18 13:33:13 2016 -0800Bug UE L1WilsonWilsonhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/41PDCP_FIFO NETLINK limited bandwidth in noS1 mode2017-08-04T14:15:45ZROBERT BenoitPDCP_FIFO NETLINK limited bandwidth in noS1 mode### Description
In noS1 mode, IP packets are read by PDCP layer using Netlink connexion with the nas_mesh driver.
A netlink read transaction is composed of two socket reads (first descriptor, second data which contains the IP frame to b...### Description
In noS1 mode, IP packets are read by PDCP layer using Netlink connexion with the nas_mesh driver.
A netlink read transaction is composed of two socket reads (first descriptor, second data which contains the IP frame to be send).
Due to a implementation bug, only one socket read was done every 1ms (PDCP scheduling opportunity given by the mac layer). Then 2 ms were required to get one IP frame form the nas_mesh driver resulting in limited bandwidth.
### Correction
check if there are still message to read in the socket before leaving PDCP layer.
Limitation : this is a quick fix and flow control is not handle. To prevent OAI stack overflow from iperf UDP, a limitation of 3 IP frames (int rlc_data_req_flag = 3;) is implemented.
### Detected in version : v1B0.6
### Impact : both UE and eNB.
### Results:
On v1B0.7 with correction we can achieve **14Mbps** in downlink (iperf UDP mode) with the following configuration : noS1 band7 5MHz mcs 28 UM modeROBERT BenoitROBERT Benoithttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/37ACK NACK for DL grant are sent on PUCCH instead of PUSCH2017-08-04T14:15:45ZGabrielACK NACK for DL grant are sent on PUCCH instead of PUSCHIn case of UL grant UE doesn't send ACK NACK on PUSCH + O_ACK is wrongly calculated.
In this case UE should send the ACK NACK only on PUSCH and not on PUCCH : add a protection for this.In case of UL grant UE doesn't send ACK NACK on PUSCH + O_ACK is wrongly calculated.
In this case UE should send the ACK NACK only on PUSCH and not on PUCCH : add a protection for this.https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/36Wrong calculation of ACK/NACK on PUSCH2017-08-04T14:15:45ZGabrielWrong calculation of ACK/NACK on PUSCHIn dci_tool the AckNack feedback is set by default for the TDD.
So the the Ack Nack is encoded at the wrong place and the eNB is decoding it always as a NACK ...In dci_tool the AckNack feedback is set by default for the TDD.
So the the Ack Nack is encoded at the wrong place and the eNB is decoding it always as a NACK ...https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/35dci format1 not decoded2017-08-04T14:15:45ZGabrieldci format1 not decodedThe problem is :
we are sometimes missing the DCI format 0 when in the same subframe we have a DCI format0 and format1.
This is coded in the following order : dci decoding format0 with aggregation level 4 then aggregation level 3 then 2...The problem is :
we are sometimes missing the DCI format 0 when in the same subframe we have a DCI format0 and format1.
This is coded in the following order : dci decoding format0 with aggregation level 4 then aggregation level 3 then 2 then 1.
The problem is that here if the format0 is decoded with aggregation level 4, it apply a Mask to CCEmap that doesn't allow the UE to decode the format1 after.
The correction is to start the decoding with Aggregation level 1 and follow with 2,3 and 4.https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/34UE MAC uplink multiplexing issues2017-09-15T11:49:35ZGhost UserUE MAC uplink multiplexing issuesThere are several issues noted in the Multiplexing function of MAC UE ULSCH(ue_get_sdu() )
- Bad multiplexing when UE has to send SRB1 and SRB2: issue in the MAC header computation, leading to unexpected transmitted RLC AM Control PDU t...There are several issues noted in the Multiplexing function of MAC UE ULSCH(ue_get_sdu() )
- Bad multiplexing when UE has to send SRB1 and SRB2: issue in the MAC header computation, leading to unexpected transmitted RLC AM Control PDU type for SRB2, discarded by the eNB or tester
- When MAC transmits data for a logical channel Id in RLC AM mode, MAC is not multiplexing several available RLC PDUs for the same LCID in the same Transport Block. This is not optimized.
- MAC always add unnecessary padding at the end of the TB when BO is greater than TBS. This is not 3GPP compliant regarding maximizing higher layer data transmission.Bug UE L2https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/33RLC AM is sometime not reporting full Buffer Occupancy to MAC2017-09-15T11:49:35ZGhost UserRLC AM is sometime not reporting full Buffer Occupancy to MACAt each TTI when MAC is requesting RLC its buffer occupancy for Tx, RLC is not reporting full BO for an AM bearer if Status PDU (ACK/NACK) is pending.
It is due to a return if ACK/NACK is pending in the middle of function rlc_am_get_buf...At each TTI when MAC is requesting RLC its buffer occupancy for Tx, RLC is not reporting full BO for an AM bearer if Status PDU (ACK/NACK) is pending.
It is due to a return if ACK/NACK is pending in the middle of function rlc_am_get_buffer_occupancy_in_bytes() before adding ReTx and newdata BO. Consequently, when a Status PDU is pending, RLC AM will only report BO for this, which is a mistake.
This is both issue for UE and eNB.Bug UE L2https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/32ulsch_start wrong calculation due to TA value change + fix for UL Harq2017-08-04T14:15:45ZGabrielulsch_start wrong calculation due to TA value change + fix for UL Harqulsch_start is wrongly calculated when we have a big TA.
The modulation done is on a negative value and the result is wrong.ulsch_start is wrongly calculated when we have a big TA.
The modulation done is on a negative value and the result is wrong.https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/26Ticket containing different fixes for OAI UE2017-08-04T14:15:45ZGabrielTicket containing different fixes for OAI UE1) Implement the max Harq transmission that was not taken into account
2) bug : all harq pid >1 for dci format 1A were discarded
3) Calculation of G, problem was due to O_RI that should be 0 when TM1 and TM2 and 1 when TM3 and TM...1) Implement the max Harq transmission that was not taken into account
2) bug : all harq pid >1 for dci format 1A were discarded
3) Calculation of G, problem was due to O_RI that should be 0 when TM1 and TM2 and 1 when TM3 and TM4
4) Bug in Harq UL Rework of the scheduling flag for the PUSCH
5) Initial sync, max freq offset limited to 150 Hzhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/25NACK problem due to wrong calculation of G2017-08-04T14:15:45ZGabrielNACK problem due to wrong calculation of GG is calculated with O_RI value but O_RI is always 1.
This value should be 0 when transmission mode is 1 or 2 and should be 1 when transmission mode is 3 or 4.
This was done properly on eNB but not on UE sideG is calculated with O_RI value but O_RI is always 1.
This value should be 0 when transmission mode is 1 or 2 and should be 1 when transmission mode is 3 or 4.
This was done properly on eNB but not on UE sidehttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/24Implement the number of Harq transmission2017-08-04T14:15:45ZGabrielImplement the number of Harq transmissionThe maxHARQ_Tx from system information is not taken into account on the UE side, this need to be implemented.The maxHARQ_Tx from system information is not taken into account on the UE side, this need to be implemented.https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/23[OAI UE] Code block of 6144 bits are ignored2017-08-04T14:15:45ZGabriel[OAI UE] Code block of 6144 bits are ignoredAs seen during execution the code block of size 6144 are discarded.
This is a bug as the max code block segmentation in LTE is 6144 bits.
In the file 3gpplte_turbo_decoder_sse_8bit.c (l.490):
if (frame_length > 6143) {
LOG_E(PHY,...As seen during execution the code block of size 6144 are discarded.
This is a bug as the max code block segmentation in LTE is 6144 bits.
In the file 3gpplte_turbo_decoder_sse_8bit.c (l.490):
if (frame_length > 6143) {
LOG_E(PHY,"compute_beta: frame_length %d\n",frame_length);
return;
}
It should be :
if (frame_length > 6144) {
...https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/20Feature UE BSR2017-08-04T14:15:45Zcalvin.wang18202157099@139.comFeature UE BSRstandardization UE BSR procedure in MAC layerstandardization UE BSR procedure in MAC layerFeature UE L2calvin.wang18202157099@139.comcalvin.wang18202157099@139.com2016-11-30https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/19Crash in USRP due to received nbsample different from requested2017-08-04T14:15:45ZGabrielCrash in USRP due to received nbsample different from requestedThis crash was due to a wrong detection of DCI0.
The RIV in dci0 is wrong which causes in pusch transmission.This crash was due to a wrong detection of DCI0.
The RIV in dci0 is wrong which causes in pusch transmission.BilelBilelhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/18OAI UE Cell sync Issue : False detection2017-08-04T14:15:45ZBilelOAI UE Cell sync Issue : False detectionI'm trying to synchronize the UE with eNB and found that it sometimes fail.
Setting USRP TX Freq 2560005400.000000, RX Freq 2680005400.000000
[PHY][I][UE_thread_synch] [UE thread Synch] Running Initial Synch (mode 0)
[PHY][I][init_fra...I'm trying to synchronize the UE with eNB and found that it sometimes fail.
Setting USRP TX Freq 2560005400.000000, RX Freq 2680005400.000000
[PHY][I][UE_thread_synch] [UE thread Synch] Running Initial Synch (mode 0)
[PHY][I][init_frame_parms] Initializing frame parms for N_RB_DL 25, Ncp 0, osf 1
lte_parms.c: Setting N_RB_DL to 25, ofdm_symbol_size 512
[PHY][I][init_frame_parms] Initializing frame parms for N_RB_DL 25, Ncp 0, osf 1
lte_parms.c: Setting N_RB_DL to 25, ofdm_symbol_size 512
[PHY][I][initial_sync] [UE0] In synch, rx_offset 31928 samples
[PHY][I][initial_sync] [UE 0] Frame 259 RRC Measurements => rssi -73.1 dBm (dig 51.9 dB, gain 125), N0 -119 dBm, rsrp -97.9 dBm/RE, rsrq 9.0 dB
[PHY][I][initial_sync] [UE 0] Frame 259 MIB Information => FDD, NORMAL, NidCell 0, N_RB_DL 25, PHICH DURATION 0, PHICH RESOURCE 1/6, TX_ANT 1
[PHY][I][initial_sync] [UE 0] Frame 259 Measured Carrier Frequency 2680003658 Hz (offset 1742 Hz)
when scanning at around +5400 Hz from the given freq in the cmd line the UE found one cell at +3658 Hz from the cmd line. This frequency has already been scanned, this one is a false detection.
It should have found it at around + 7200 Hz.
See for reference, Pass log
Setting USRP TX Freq 2560005400.000000, RX Freq 2680005400.000000
[PHY][I][UE_thread_synch] [UE thread Synch] Running Initial Synch (mode 0)
[PHY][I][init_frame_parms] Initializing frame parms for N_RB_DL 25, Ncp 0, osf 1
lte_parms.c: Setting N_RB_DL to 25, ofdm_symbol_size 512
[PHY][I][init_frame_parms] Initializing frame parms for N_RB_DL 25, Ncp 0, osf 1
lte_parms.c: Setting N_RB_DL to 25, ofdm_symbol_size 512
[PHY][I][initial_sync] [UE0] In synch, rx_offset 1116 samples
[PHY][I][initial_sync] [UE 0] Frame 228 RRC Measurements => rssi -73.1 dBm (dig 51.9 dB, gain 125), N0 -119 dBm, rsrp -97.8 dBm/RE, rsrq 9.0 dB
[PHY][I][initial_sync] [UE 0] Frame 228 MIB Information => FDD, NORMAL, NidCell 0, N_RB_DL 25, PHICH DURATION 0, PHICH RESOURCE 1/6, TX_ANT 1
[PHY][I][initial_sync] [UE 0] Frame 228 Measured Carrier Frequency 2680007101 Hz (offset -1701 Hz)
[HW][I][UE_thread_synch] Got synch: hw_slot_offset 0
Setting USRP TX Freq 2560007101.000000, RX Freq 2680007101.000000Bug UE L1BilelBilel