This commit is properly allocating the NR nFAPI
messages on the heap; however, when we do this,
it makes the NR UE behind the gNB even more and
casuses us to not finish the CFRA procedure. This
is because the RAR is recevied in the NR UE, but
the slot indications are too far in advance, so
the CRC/RX pair (msg3) is never sent because
the scheduled ul_slot and ul_frame already was
received prior to getting the RAR.
Need to fix this!!
This commit allows us to call the scheduler for
every slot indication we get to ensure we properly
configure the DCI. Also, we are sure to process the
DCI only when we have both the config (dl_tti) and
the payload (tx_req). Lastly, removed the hack
to the slot indication (we do not shift the slot
indication by -6 anymore). We are passing up to 4
NSA UEs, but sometimes one will not complete the CFRA
procedure.
- replaced taus with a random seed + random number generation
- this fixes the bug with multiple UEs starting RA in the same time frame and slot
and selecting the same preamble index
This commit changes the stub functionality entirely.
We are now queueing any received NR nFAPI message
and handling it only after we recevie a slot ind
that corresponds with the nFAPI message's sfn/slot
value. When doing this, an existing issue has been
brought to light. The gNB and NR UE are not in sync
when it comes to their slot indications. Generally,
the NR UE seems to be ahead of the gNB by around 6-7
slots. This commit has a hack... when we receive a
slot indication at the moment, we decrament it by 6
to try to keep the NRUE from being ahead of the gNB.
This will be fixed shortly... This was a temporary
fix..
By reverting this change, we will see the NRUE2 crash
because the DCI wont be configured before handling.
This will get fixed in the next commit by adding
queues for the nFAPI messages, therefore forcing
us to handle the nfapi messages only after we have
processes the corresponding slot indication.
- Estimates correct MCS using EMA, kept between target thresholds
dl_bler_target_upper and dl_bler_target_lower (conf options) for 1st
retx and below dl_rd2_bler_threshold for 2nd retx
- Maximum MCS configurable
- on 3rd retx, reduce MCS by 5
In this commit we were trying to understand why
the memset of the def_dci_pdu_rel15 array in the NRUE
was casuing the NR UE to crash. This was happening
becuase some of the members of the def_dci_pdu_rel15
array canont be zero in NSA mode. This was happening
because sometimes, we would recevied two DCI indications
in a row, after the first one, we would be memesetting
the array to all 0s and then try to process the second
DCI. The fix we have implemnted is to call the configure_dci()
prior to processing ANY DCI, to ensure we have properly
configured the UE to handle these DCIs.
Also, in the gNB, it was not able to find the UL scheduled
slot for the feedback harq because it was not accounting for
the slot wrapping.
-F1 message successfully encoded at the CU (including SRB2, DRB and F1-U tunnel configuration) and received from the DU.
-Next steps: handling of UE context modification request at the DU and triggering the UE context setup response towards the CU.
Removing the memset seemed to hide the problem
and now the problem is appearing in a differnt
manner... it is causing the NRUE to skip HARQ
PIDs as its filling the UCI indication and process
the DCI PDUs. So adding the memset causes the NR UE
to crash becasue the DL_BWP_ID is becoming 0
which leads us to index into an pointer that is not
allocated and then a crash happens in DCI handling.
This requires some updates to the nFAPI code as well.
We also have declared the def_dci_rel15 extern variable
consistently throughout the code.
In this commit, the gNB is still crashing. However, it seems
that the NSA UE is sending the proper responses back, but there
some sort of incorrect management of the def_dci_pdu_rel15
variable. If we memset this array to 0, we can see incorrect
0 assignments to elements of the UCI indications. Hopefully
fixing this issue will result in less gNB crashes.
luis_pereira87