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
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.
Several problems are present.
The first is that _write returns 0 instead of the
number of samples. We solve it by returning
nsamps.
The second is that _read may return less samples at
the beginning and we don't want to exit for that.
We solve it also by returning nsamps.
(We still need to log more in this, to be done in the
next commit.)
The third is that after initialization we don't send
anything for a while, time for the softmodem to finish
its init. This generates lots of "RX overrun".
We solve it by disabling TX and RX modules after init
and then in trx_brf_start we activate them again (and
also call bladerf_sync_config, which seems to be
mandatory, and bladerf_calibrate_dc, which may be avoided,
perhaps).
Maybe not the end of the story. Sometimes it works, UE connects,
traffic is fine (tested only with 5MHz). Sometimes it does not,
UE does not connect, or it connects but then traffic is bad,
especially uplink.
To be refined.
develop_integration_w22 into develop
Summary of changes:
- UE:
* TDD multiplexing
* TDD autotest
* bug fixes: power control management for Msg3, logging
- eNB:
* CCE allocation fixes
* S1U port in some configuration files set to 2152 (was 2153)
- support for RedHat enterprise linux 7 and derivatives (CentOS, ...)
(work provided by RedHat)
See merge request !198
- rename UE_NO_LOG to DISABLE_LOG_X
because the name is misleading. The full software
is impacted, not only the UE part
- same for compilation option ---ue-no-log
that becomes --disable-log
- keep LOG_X for the standard case, that is the
case without DISABLE_LOG_X where printf has been
put. Two reasons:
* printf is not realtime friendly
* keep behavior similar for other users who may
be troubled by different logs that don't add
any benefit to previous logs
Cedric Roux