- fix compilation of dlsim/ulsim/oaisim by defining some needed
global variables
- fix compilation of oaisim: compile coding and params_libconfig
- fix running of if4p5 with low CPU count (oaisim was not working
on the machine 'haswell' because of this)
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
There is now the function copy_harq_proc_struct and some
procedures for the UE have changed, which makes necessary
to have UE->dlsch valid for both subframes (odd and even).
We increase memory usage, maybe it's not the correct solution.
To be kept in mind if something goes wrong at some point.
When you ran it with the scope as:
./dlsim -X
you saw no activity in the "PDSCH I/Q of MF Output" window,
so matter what SNR you put (even for very high SNR, say: ./dlsim -X -s40)
this commit seems to fix it.
I am not sure it is the end of story. The 2 threads PDCCH/PDSCH structures
may still not be used correctly everywhere.
the argument 'coded_bits_per_codeword' has to be an array in
case of several codewords.
The calling sites have been adapted.
Today, only the first index is used, so calling sites where
'coded_bits_per_codeword' is an integer pass the address
of it. It is expected that 'dump_dlsch2' will check in the
future that there is one or two codewords and only access
'coded_bits_per_codeword[1]' when it's sure there are
really two codewords.
Raphael Defosseux