Merge branch 'sp3_rlc_assertion' of http://10.37.145.15:8000/gitlab/vran/release_enb into sp3_rlc_assertion

Merge branch 'sp3_rlc_assertion' of http://10.37.145.15:8000/gitlab/vran/release_enb into sp3_rlc_assertion

# Conflicts:
#	openair2/LAYER2/RLC/rlc.c

Sp3 tdd config1

See merge request !31

(cherry picked from commit 0e550a32e46d797d03fd72e54e474762d4db7614)

# Conflicts:
#	openair2/LAYER2/RLC/rlc.c

・Delete double BSR calculation.
・change TBS for mcs setting bit to byte.

(cherry picked from commit 39cd022424ebe98c95be32cbb4127aa9d0e0ff3b)

Fix: segmentation fault happens when clean_eNb_dlsch() function is executed while pdsch procedure running.

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

Fix: Random access information is not released when Msg3(response to PDCCH order) re-transmission fails.

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)