- 07 Aug, 2017 2 commits
- 03 Aug, 2017 6 commits
-
-
Cedric Roux authored
Summary of changes: - UE: new thread idx - UE: Pdcch optim - UE: slot0 slot1 parallelization - bugfixes for RLC AM (see gitlab issue 250) - fix bug "unknown UE_id for rnti" Note: due to the new UE threading architecture, oaisim and the phy simulators may not work properly anymore. Adaptation in the code has been done, automatic tests seem to pass, but it may not be enough. See merge request !215
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
-
Cedric Roux authored
With the new threading architecture of the UE dlsim (and others) does not work properly anymore. When looking at the scope, you see a difference in PDSCH LLR display. The end is always 0 where in the current develop branch (tag 2017.w25) it's not. This commit attempts to fix it. We still don't have the same behavior as in 2017.w25. I disabled channel simulation (so that UE RX = eNB TX) and I have one error where in 2017.w25 I have zero. For example, here comes the output of a run of "./dlsim": **********************SNR = 0.000000 dB (tx_lev 51.000000)************************** Errors (1(0)/1000 0/1 0/0 0/0), Pe = (1.000000e-03,0.000000e+00,-nan,-nan), dci_errors 0/1001, Pe = 0.000000e+00 => effective rate 99.900100, normalized delay 0.001472 (1.001000) And in 2017.w25 we have (with the same hack to disable channel simulation): **********************SNR = 0.000000 dB (tx_lev 51.000000)************************** Errors (0(0)/1000 0/0 0/0 0/0), Pe = (0.000000e+00,-nan,-nan,-nan), dci_errors 0/1000, Pe = 0.000000e+00 => effective rate 100.000000, normalized delay 0.001471 (1.000000) There may be a problem somewhere. Or there was one before and we should have had one error and the new UE architecture fixed things and now it's as it has to be. Hard to say at this point... When looking at the scope we quickly see some zeros for the PDSCH LLR, at the begining this time, not at the end. This is just when the GUI appears and then all is fine, so this seems to be for the first frame only. In 2017.w25 this does not happen.
-
Cedric Roux authored
-
- 01 Aug, 2017 2 commits
- 31 Jul, 2017 4 commits
-
-
Cedric Roux authored
With the current implementation of oaisim (rxdata and channel simulation), we cannot call trx_read_func on a dummy buffer. The code will actually modify the rxdata buffers of the UE. This is has to be rewritten properly. In the meantime, let's introduce a simple hack. The idea of the read at this point is to wait for the synch to finish and not lose samples from the hardware in the real UE. In the simulator, as it is today, we can simply sleep until the synch code has finished its work.
-
Cedric Roux authored
In case of oaisim, dl_phy_sync_success has to be called by initial_sync, as it used to be. We introduce an #if OAISIM, this is not elegant, but will do it for the moment.
-
tct-labo4 authored
-
tct-labo4 authored
-
- 28 Jul, 2017 2 commits
-
-
gabrielC authored
-
Cedric Roux authored
Merge remote-tracking branch 'origin/bugfix-258-unknown-ue-id-for-rnti' into develop_integration_w30
-
- 27 Jul, 2017 1 commit
-
-
Cedric Roux authored
This bug happens when we detect uplink failure for one UE. In this case, a DCI format 1A is sent to the UE to ask it to do random acces. The way this DCI is generated was not compatible with how the software is organized. It was expected that the DCI are added (with add_ue_spec_dci and add_common_dci) in a very specific order: first all DCIs in common space are added (with add_common_dci) then all DCIs in UE specific space are added (with add_ue_spec_dci). The problem was that the DCI format 1A DCI sent to the UE for it to do random access is added (with add_ue_spec_dci) before the DCIs in common space. That totally messed up the logic in add_common_dci and add_ue_spec_dci. The solution is to get rid of Num_common_dci and Num_ue_spec_dci, replace those two counters by only one (Num_dci) and add "search_space" in the dci_alloc structure to be used later by the function "allocate_CCEs" when calling "get_nCCE_offset". The software had to be adapted to the new variables, everywhere. I am not sure that the simulators work. It seems that some of them didn't use Num_common_dci and Num_ue_spec_dci to decide on what space (common or UE specific) to put the DCI, but relied on the rnti (comparing with SI_RNTI). To be tested properly. The modified simulators are: - openair1/SIMULATION/LTE_PHY/dlsim.c - openair1/SIMULATION/LTE_PHY/dlsim_tm4.c - openair1/SIMULATION/LTE_PHY/dlsim_tm7.c - openair1/SIMULATION/LTE_PHY/framegen.c - openair1/SIMULATION/LTE_PHY/pdcchsim.c - openair1/SIMULATION/LTE_PHY/syncsim.c
-
- 26 Jul, 2017 2 commits
- 20 Jul, 2017 1 commit
-
-
hbilel authored
-
- 18 Jul, 2017 1 commit
-
-
fnabet authored
-
- 17 Jul, 2017 6 commits
- 06 Jul, 2017 1 commit
-
-
gabrielC authored
Optimisation of rx_pdcch : save some time by reading one symbol pdcch first and read symbol 2 and 3 if needed Optimisation of nb of candidate when searching DCI
-
- 04 Jul, 2017 1 commit
-
-
gabrielC authored
-
- 29 Jun, 2017 2 commits
- 28 Jun, 2017 1 commit
-
-
tct-labo4 authored
-
- 27 Jun, 2017 2 commits
- 26 Jun, 2017 2 commits
-
-
fnabet authored
-
Cedric Roux authored
develop_integration_w25 into develop Summary of changes: - UE: configurable thread - UE: fix in dci format1c decoding - bladeRF hack - configuration files for oaisim See merge request !209
-
- 23 Jun, 2017 4 commits
-
-
Cedric Roux authored
-
Cedric Roux authored
changes: - ue mcc/mnc 208.93 - use correct key/opc for user - change addresses in conf file for them to be easier to understand (maybe) With those changes, running: sudo ./run_enb_ue_virt_s1 in cmake_targets/tools should work out of the box The user still has to configure correct IP addresses in targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.generic.oaisim.local_mme.conf We supposed oaisim (enb+ue) machine to be on IP address 10.0.1.1 and EPC (hss, mme, spgw) machine to be on IP address 10.0.1.2.
-
Cedric Roux authored
-
Cedric Roux authored
-