openairinterface5G issueshttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues2018-12-07T12:59:16Zhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/50ULSCH consecutive error2018-12-07T12:59:16ZGhost UserULSCH consecutive errorUE is removed by eNodeB because ULSCH consecutive error count is reached.
We have eNB compiling and running on LMSSDR, however we still have issues achieving and maintaining attach complete with UE.
Below were the error appeared in eNB...UE is removed by eNodeB because ULSCH consecutive error count is reached.
We have eNB compiling and running on LMSSDR, however we still have issues achieving and maintaining attach complete with UE.
Below were the error appeared in eNB…
[MAC][I][eNB_dlsch_ulsch_scheduler] UE rnti 5452 : in synch, PHR 40 dB
[RRC][I]UE rnti 5452 failure timer 0/20000 [PHY][I]UE 0 : rnti 5452
[MAC][I][eNB_dlsch_ulsch_scheduler] UE rnti 5452 : in synch, PHR 40 dB [RRC][I]UE rnti 5452 failure timer 0/20000
[PHY][W][eNB 0, CC 0] frame 310, subframe 2, UE 0: ULSCH consecutive error count reached 20, triggering UL Failure
[MAC][I][UL_failure_indication] [eNB 0][UE 0/5452] Frame 310 subframeP 2 Signaling UL Failure for UE 0 on CC_id 0 (timer 0)
[PHY][E]ERROR: Format 1A: rb_alloc (1ff) > RIV_max (144) [PHY][E]ERROR: Format 1A: rb_alloc (1ff) > RIV_max (144)
[PHY][E]ERROR: Format 1A: rb_alloc (1ff) > RIV_max (144) [PHY][E]ERROR: Format 1A: rb_alloc (1ff) > RIV_max (144)
[PHY][E]ERROR: Format 1A: rb_alloc (1ff) > RIV_max (144)
[MAC][I][eNB_dlsch_ulsch_scheduler] UE 0 rnti 5452: UL Failure after repeated PDCCH orders: Triggering RRC [RRC][I]Frame 330, Subframe 1: UE 5452 UL failure, activating timer MAC: remove UE 0 rnti 5452
[MAC][I][rrc_mac_remove_ue] Removing UE 0 from Primary CC_id 0 (rnti 5452)
[RRC][I]UE rnti 5452 failure timer 6940/20000
[RRC][I]UE rnti 5452 failure timer 17180/20000
[RRC][I]Removing UE 5452 instance
[RRC][W][eNB 0] Removing UE RNTI 5452 MAC: cannot remove UE rnti 5452
[MAC][W][rrc_mac_remove_ue] rrc_mac_remove_ue: UE 5452 not found
[S1AP][W][s1ap_ue_context_release_req] Failed to find ue context associated with eNB ue s1ap id: 0
[S1AP][E][s1ap_eNB_task] Failed to find ue context associated with eNB ue s1ap id: 0
[RRC][I][FRAME 00000][eNB][MOD 00][RNTI 5452] Removed UE context [INFO] L 4266779680 [INFO] L 4343611520
Can u please share us how did u solved this problemhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/49automatize UE network settings2017-08-29T16:52:25ZCédric Rouxcedric.roux@eurecom.frautomatize UE network settingsThere could be a command-line option to setup network:
- set IP address
- set route
- set DNS (/etc/resolv.conf)
This should be done in a separate thread, not the realtime one
(the IP setting is don;, at some point it was done in the r...There could be a command-line option to setup network:
- set IP address
- set route
- set DNS (/etc/resolv.conf)
This should be done in a separate thread, not the realtime one
(the IP setting is don;, at some point it was done in the realtime
thread, I don't know how it is as of today).https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/48add logs to UE_IP kernel module2017-08-29T16:52:25ZCédric Rouxcedric.roux@eurecom.fradd logs to UE_IP kernel moduleThe module calls kernel functions (like netif_rx) which return something (I did not analyse exactly what).
We should check the returned value to ease development/debugging.The module calls kernel functions (like netif_rx) which return something (I did not analyse exactly what).
We should check the returned value to ease development/debugging.https://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/40Initial synchronization2017-08-29T16:52:25ZThomas Laurentlaurent.thomas@open-cells.comInitial synchronizationFrom my understanding of the file lte-ue.c
A main thread: UE_thread
always acquire I/Q from the RF board and keep it synchronous
This thread calls other threads to process the I/Q
In the case of this report, the UE is not yet synchrono...From my understanding of the file lte-ue.c
A main thread: UE_thread
always acquire I/Q from the RF board and keep it synchronous
This thread calls other threads to process the I/Q
In the case of this report, the UE is not yet synchronous with the serving eNB
So, the thread calls the dedicated thread to sync (with a full frame of I/Q samples)
Waiting the result, it continues to read frame per frame (and trash it), until it gets the result of the sync detection thread
When the result is done and positive, it shifts of the right number of I/Q the buffers to be sync with the eNB
A thread: UE_thread_synch try to decode the PBCH in a acquired full frame
But, this thread manipulate the RF board: it starts and stop it
So, the main thread acquisition become completely corruptedhttps://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/39UE Periodic DL Throughput drop2017-08-29T16:52:25ZGhost UserUE Periodic DL Throughput dropUE periodic throughput drop on downlink (Band7 5MHz MCS28, --phy-test AND noS1 modes)
Period is about 490ms
**Version of OAI UE : v1B0.7**
**Frequency : each run**
**Configuration :**
* OAI UE : USRP B210
* OAI eNB : USRP B2...UE periodic throughput drop on downlink (Band7 5MHz MCS28, --phy-test AND noS1 modes)
Period is about 490ms
**Version of OAI UE : v1B0.7**
**Frequency : each run**
**Configuration :**
* OAI UE : USRP B210
* OAI eNB : USRP B210
**Attached files :**
* --phy-test
![UE_5MHz_MCS28_Throughput_phytest](/uploads/5018d273da86eccff9db7834cc4bcbde/UE_5MHz_MCS28_Throughput_phytest.png)
* noS1 (iperf)
![UE_5MHz_MCS28_Throughput_iperf](/uploads/3f54fe8bb377806dc833440180625f29/UE_5MHz_MCS28_Throughput_iperf.png)https://gitlab.eurecom.fr/oai1B/openairinterface5g/-/issues/38UE Segmentation Fault after EnodeB stopped first2017-08-29T16:52:25ZGhost UserUE Segmentation Fault after EnodeB stopped firstThis is a segmentation fault at UE when eNodeB stopped first after a RRC connection.
**Version of OAI UE : v1B0.7**
**Frequency : each run**
**Configuration**
* OAI UE : USRP B210
* OAI eNB : USRP B210
**Backtrace from gdb...This is a segmentation fault at UE when eNodeB stopped first after a RRC connection.
**Version of OAI UE : v1B0.7**
**Frequency : each run**
**Configuration**
* OAI UE : USRP B210
* OAI eNB : USRP B210
**Backtrace from gdb**
`Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffda4d7700 (LWP 3389)]
0x00007ffff6a01113 in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
backtrace:
#0 0x00007ffff6a01113 in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
No symbol table info available.
#1 0x00007fffdc46902a in trx_usrp_read (device=0x7ffff7edcc48, device@entry=<error reading variable: Cannot access memory at address 0xff5cfff5ff2b010e>, ptimestamp=0x7fffdc46902a <trx_usrp_read(openair0_device*, openair0_timestamp*, void**, int, int)+1226>, buff=0x1605ad00, nsamps=196612, cc=1) at /home/yanbo/openair5g/oai161201v1B0.7/openairinterface5g/targets/ARCH/USRP/USERSPACE/LIB/usrp_lib.cpp:262`https://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/31eNB TDD mode Segmentation FAult2017-08-29T16:52:25ZROBERT BenoiteNB TDD mode Segmentation FAultThere is a segmentation fault at eNB start-up that prevent run it
#### Version of OAI eNB : v1B0.4
#### frequency : each run
#### configuration : see issue #27
#### backtrace from gdb
`
got sync (eNB_thread_single)
Program received sig...There is a segmentation fault at eNB start-up that prevent run it
#### Version of OAI eNB : v1B0.4
#### frequency : each run
#### configuration : see issue #27
#### backtrace from gdb
`
got sync (eNB_thread_single)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffce43b700 (LWP 26645)]
trx_usrp_read (device=<optimized out>, ptimestamp=0x7ffff00c8020, buff=0x7fffce43ae10, nsamps=7680,
cc=1) at /tmp/oai_develop1B_tdd/openairinterface5g/targets/ARCH/USRP/USERSPACE/LIB/usrp_lib.cpp:270
270 ((__m256i *)buff[i])[j] = _mm256_srai_epi16(buff_tmp[i][j],4);
`