GitLab

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

re-adding the possibility in dlsim to bypass the DCI/PDCCH generation. This is necessary for accuracy of the dlsim-tests, which are working again now.

Gabriel authored May 11, 2017 and Cedric Roux committed May 12, 2017

Note: not sure that the code is correct,
to be checked (Cédric Roux).

----------------------------------------------------------
bug 22

Ttile:
(subframe!=2)||(subframe!=7) is always TRUE. This coding
is really intended? Operator || should be && instead?

Bug Location:
((frame_parms->frame_type==TDD)&&(frame_parms->tdd_config==1)&&((subframe!=2)||(subframe!=7)))) {

Note:
Detected by CppCheck
----------------------------------------------------------

- import RRC ASN.1 defintions from the specifications
  (file openair2/RRC/LITE/MESSAGES/asn1c/ASN1_files/RRC-e10.asn)
  contrary to rel8/10, all modules have been imported, maybe it's too much
  to refine in case of problems
- deal with rel14 in fix_asn1
- all code that was for Rel10 is now for Rel10/Rel14
- some incompatible changes (mostly in naming) were resolved in favor
  of rel14, see in openair2/RRC/LITE/defs.h
- unsure about the rlc layer, some arrays have changed (values appended),
  I only changed the definition and in tests in the code, I changed
  the index limit, maybe it's not enough

Rel14 is the default compilation mode.

768*8 is too small, in 20MHz, the phy-test mode
(in default mode?) has a buffer of size 6378.

Let's set the buffer size to the input's one plus 4 bytes
(to accomodate for CRC, not sure about this).

Conflicts:
	openair1/PHY/INIT/lte_init.c
	openair1/PHY/LTE_TRANSPORT/dlsch_modulation.c
	openair1/PHY/LTE_TRANSPORT/power_control.c

Some of them might not be correctly handled.
I put /* TODO: XXX */ where I didn't know if
the fix was correct.

fixes for precoding (turning off if nb_antennas_tx=1), configuration files, timing advance with 3/4 sampling on 20 MHz, logging in MAC

ROBERT Benoit authored Dec 05, 2016 and ROBERT Benoit committed Dec 14, 2016

correct issue 147 : --phy-test mode : error msg " DL Received HarqReTx round=1 mcs=28 rballoc=8191 rv=0 "

correct issue 147 : --phy-test mode : error msg " DL Received HarqReTx round=1 mcs=28 rballoc=8191 rv=0 "

- add mcs to ENB_PHY_DLSCH_UE_DCI
- add mcs, round, first_rb, nb_rb, TBS to ENB_PHY_ULSCH_UE_DCI

Something went wrong somewhere in the commit history, the function
was not correct.

The most obvious symptom was that way too much SR (scheduling requests)
were given to the UE whenever it had some PUCCH to send.

The case for TDD has not been tested.

The eNodeB may sometimes wrongly generate PHICH because somewhere
'phich_active' is not reset to 0, due to an unidentified reason. When
adding this hack the problem seems to disappear completely.

This is not the end of the story. The real underlying problem has to be
understood and fixed correctly.

The Msg3 ressource blocks used by random access procedure
were not correctly handled. The MAC scheduler could wrongly
allocate a ressource block for both random access Msg3 and
a regular UE.

This hotfix hopefully fixes the problem.

A new function "set_msg3_subframe" has been added in the
interface between PHY and MAC.

- Msg3 allocation
- initiation of Random Access procedure

The PHICH generation is wrong.
HARQ process X is uplink scheduled at TTI n.
At TTI n+4 the eNB receives the data.
At TTI n+8 the eNB sends ACK/NACK on the PHICH.

The problem is that PHICH generation is done after scheduling.
And PHICH generation uses "first_rb" and "n_DMRS" to compute
"ngroup_PHICH" and "nseq_PHICH".

So at TTI n+8 if the eNB has reused the HARQ process X for
a new uplink scheduling the values "first_rb" and "n_DMRS"
may have changed.

We need to use the previous values.

One solution would have been to do PHICH generation before
scheduling. The problem is that "generate_phich_top" does more
than PHICH generation. It has to setup parameters to sort of
"emulate" a DCI0 in case of retransmission scheduled without
DCI0. So part of it has to be done after scheduling. We would
have to split the function.

The simple adopted fix is to store old values of "first_rb"
and "n_DMRS" and use those values in "generate_phich_top".

This fix has only been tested with FDD. TDD may miserably fail.