MCSTable mismatch upon retransmissions of RRCReconfiguration
When we have multiple retransmissions of RRCReconfiguration, in which the MCSTable is updated, it can happen that a retransmission is sent after the new table is applied (RRC Processing Timer expires).
When this happens the MCSTableIdx will, for example, not match the targetcoderate for that message, which was calculated with the previous MCSTable, and not updated when the new one is applied.
With OAI L1, we see that this causes the UE to lose connection, and then triggers a new RA, but, with a 3rd party L1, namely Aerial, when this happens, it asserts, not permitting recovery. The current workaround is to detect when the PDSCH_PDU MCSTableIdx doesn't match with the TargetCoderate in the same PDU, and force the table index to be 0 in that case.
This can be reproduced in OAI by forcing the messages to be retransmitted at least twice, in which case some retransmissions may be sent after the RRC Processing timer expires.
The current workaround is as follows: gNB_scheduler_dlsch.c in function nr_schedule_ue_spec and before
AssertFatal(harq!=NULL,"harq is null\n");
// NVIDIA: Workaround for MCSTableIdx mismatch error
if (nr_get_code_rate_dl(sched_pdsch->mcs, current_BWP->mcsTableIdx) != R) {
pdsch_pdu->mcsTable[0] = 0;
}