- included MAC CE sub-PDUs size in the computation of RLC data to transmit
this fixes the error with residual mac pdu appearing at gNB side when
transmitting higher amount of data
- got rid of the nr_generate_ulsch_pdu and moved the relevant UL-SCH MAC PDU
generation procedure within the nr_ue_get_sdu and nr_ue_get_rach
- reduced memcpy calls and unnecessary memory allocations
- fetching RLC data and SDU size from the mac_rlc_data_req, removed the call
to mac_rlc_get_buffer_occupancy_ind
- introduced a new function to generate the MAC CEs sub-PDUs
- removed unnecessary function input parameters
- minor fixes and cleanup
- enhanced logging
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).
cig