Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

MR !1206 : nr_ue_remove_high_speed_flag
This flag is always set to 1, 
With multiple DMRS symbols configuration, very recent DMRS containing symbol shall be for channel estimation.

MR !1205 : fix-lte-ue-modem-in-docker-container
We bind the socket to any_addr (instead of localhost), so the commands to the UE can come also from a remote machine

MR !1178 : NR_CSIRS_tomerge
Implementation of CSI RS transmission at gNB

MR !1211 : develop-NSA_SA_fixes
Small fixes for NSA and SA

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Merge remote-tracking branch 'origin/fix-lte-ue-modem-in-docker-container' into integration_2021_wk30

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

MR !1193 : Update for 5G SA implementation

When there is a retransmission, we want to use the same number of RBs.

The RBs are allocated by groups (RBGs).

In some cases (like a cell with 25 PRBs), the last RBG contains less RBs.
So in case of a retransmission, if this last RBG was used before we need
to reuse it to have the same number of RBs. If not, we will use more RBs
for the retransmission than the previous transmission.

In an experiment with two UEs (quectel modules) it was seen that when a
retransmission happens with a different number of RBs then the UE is not
happy at all, leading to way more NACKs in the harq processes than should
happen (actually the first NACK was not a NACK at all, but the eNB did
interpret it as a NACK; so the next transmission should simply be discarded
by the UE that successfully received the first transmission; instead the UE
fails to decode the data and sends a NACK, a real one this time).

Maybe it's not the correct solution, but it improve things, there are
much less NACKs.

The problem is that when using those RBs with MCS 28 we may exceed the
code rate 0.93 and according to 36.213 7.1.7 the UE may skip decoding
PDSCH entirely in this case.

This is a hack. The real solution is to check that the code rate is below
0.93 for each scheduling decision and, I don't know, reduce the MCS if the
code rate is above, so that in the end it is below. That means that we need
a proper resource grid for the configuration of the eNB and this is not an
easy thing (at least from my point of view) given all the possible
configurations for the eNB, so I prefer not to do it rather than do something
incorrect, thus this hack.

The problem of this hack is that we won't use all the available RBs for
scheduling, potentially reducing the maximum throughput achievable.

To be fixed properly at some time, by someone who understands fully the
resource grid and all the possible combinations (fdd/tdd, number of
antennas, whatever else).

[CI] for gNB Phy test : update of the execution timings ref values, according to the latest developments