- May 29, 2018
-
-
Haruki NAOI authored
This reverts commit c652a883.
-
- May 24, 2018
-
-
Haruki NAOI authored
-
Haruki NAOI authored
This reverts commit 24c669f3.
-
Masayuki HARADA authored
-
- May 21, 2018
-
-
jftt_wangshanshan authored
-
- May 17, 2018
-
-
Masayuki HARADA authored
-
- May 16, 2018
-
-
Masayuki HARADA authored
-
- May 15, 2018
-
-
Masayuki HARADA authored
-
Wu Jing authored
-
Wu Jing authored
-
- May 09, 2018
-
-
jftt_wangshanshan authored
Fix cqi_req_flag, to prevent continously schedule cqi after set it to 1 and before actually receive it at the right subframe.
-
- May 07, 2018
-
-
Wu Jing authored
-
- Apr 26, 2018
-
-
Masayuki HARADA authored
-
- Apr 22, 2018
-
-
jftt_wangshanshan authored
-
jftt_wangshanshan authored
-
- Apr 16, 2018
-
-
Haruki NAOI authored
-
- Apr 10, 2018
-
-
Wu Jing authored
-
- Mar 20, 2018
-
-
Haruki NAOI authored
Fix: segmentation fault happens when clean_eNb_dlsch() function is executed while pdsch procedure running.
-
- Mar 16, 2018
-
-
Haruki NAOI authored
-
Cedric Roux authored
As reported by Emad Alizade: According to "Issue255 256 257 paging reesta release" that has been merged in develop version, we have a question: In rrc_eNB_free_UE() function only all ulsch related memory of user has been cleaned, but I think not only ulsch memory but also dlsch memory must be cleaned. I tested the latest develop version and with repetition UE attach-detach procedures we find that the dlsch memory has not been cleaned and after repeat this sequence (45 times) assertion with cause UE_id!=-1 (no free or exiting dlsch_context, dci_tools.c: fill_dci_and_dlsch() ) occurred and no UE will be attached to system. The fixes in this commit are from Emad Alizade. (cherry picked from commit 4b5b5564) # Conflicts: # openair1/PHY/LTE_TRANSPORT/dlsch_coding.c # openair2/LAYER2/MAC/eNB_scheduler.c # openair2/RRC/LITE/rrc_eNB.c
-
- Mar 08, 2018
-
-
Wu Jing authored
-
- Mar 01, 2018
-
-
Wang.shanshan authored
-
- Feb 27, 2018
-
-
Cedric Roux authored
The problem is the following (as reported by an user): "one UE is attached to OAI system. UE is near the antenna. Try to detach the UE and attach again. Repeat this procedure for 5-6 times. OAI system does not work and any the UE can not attach to this system. I use TEMS software and I can see MIB signaling on this UE but UE can not decode SIB1 and SIB2." What happens is that the DCI for SIB1 and SIB2 is not cleared before use. That is the bits in the 'padding' field keep the values that were set before. If the structure has been used to transmit other DCIs (eg. for UEs) in the past, it may be reused with some of those bits set to 1. When receiving this DCI, the UE won't accept it because it gets some bits at 1 where it expects them to be 0. The short-term/quick solution is to clear the 'padding' field. A better solution would be to rewrite this part of the code, which is way too complicated for what it does. But this takes too much time. In dci.h the field 'dummy' of some structures was renamed to 'padding'. The fields 'padding32' and 'padding64' were also renamed to 'padding' for consistency. Some structures (DCI2B_1_5MHz_TDD, DCI2B_10MHz_FDD, DCI2D_1_5MHz_FDD, DCI2D_5MHz_FDD, DCI2D_10MHz_FDD) had a 'padding' field at the end, which was renamed to 'padding0'. I don't know if this field should be here at all. To me this field looks very suspicious. When we test DCIs 2B and 2D we should be careful. (cherry picked from commit c5ca2bd8)
-
- Feb 20, 2018
-
-
tomita authored
-
- Feb 19, 2018
-
-
tomita authored
-
- Feb 13, 2018
-
-
naoi authored
-
- Feb 12, 2018
-
-
jftt_wangshanshan authored
-
- Feb 11, 2018
-
-
jftt_wangshanshan authored
-
jftt_wangshanshan authored
-
- Feb 08, 2018
-
-
jftt_wangshanshan authored
Fix bug in subframe2harq_pid. Remove if tdd condition while calling this method since there is already if-else in the method.
-
- Feb 07, 2018
- Feb 06, 2018
-
-
jftt_wangshanshan authored
-
- Feb 05, 2018
-
-
jftt_wangshanshan authored
-
jftt_wangshanshan authored
-
- Jan 23, 2018
-
-
Xu Bo authored
-
- Jan 22, 2018
-
-
Cedric Roux authored
As reported by Emad Alizade: According to "Issue255 256 257 paging reesta release" that has been merged in develop version, we have a question: In rrc_eNB_free_UE() function only all ulsch related memory of user has been cleaned, but I think not only ulsch memory but also dlsch memory must be cleaned. I tested the latest develop version and with repetition UE attach-detach procedures we find that the dlsch memory has not been cleaned and after repeat this sequence (45 times) assertion with cause UE_id!=-1 (no free or exiting dlsch_context, dci_tools.c: fill_dci_and_dlsch() ) occurred and no UE will be attached to system. The fixes in this commit are from Emad Alizade.
-
Xu Bo authored
-
Xu Bo authored
-
- Jan 16, 2018
-
-
bruno mongazon authored
-