- The DL MCS adapted based on the BLER for the minimum number of
DL(numd_sched) grants for the UE in the pre_configured number of frames.
The current threshold value is set to be >9 for 16 UE capacity.
- With increased number of UE to 32 and when all the UEs are DL data active
the num_dl_sched is not meeting the threshold value. Due to whcih the MCS
of all the UEs are stuck with MCS 10-12 in good channel condition.
- The threshold value is adjusted to support 32 UE capacity increase.
- Added the limit as MAX_DCI_CORESET for max_sched_ues in DL/UL scheduler.
This is needed because gNB crashes when tested with 100MHz cell as the
scheduler tries to schedule 11 UEs in a slot and the DCI informaiton is
corrupted due to the limitation in NFAPI interface because of
MAX_DCI_CORESET size.
The F1AP message encoders and decoders should do only that, encoding and
decoding messages. For the actual logic handling, including set up and
teardown of bearers, we should use the handlers.
In this commit, delete GTP tunnel handling from encoders/decoders. For
the CU, this happens already in the CU-UP/E1 handlers in
cucp_cuup_handler.c. For the DU, add it in the handlers in
mac_rrc_dl_handler.c.
From the spec, it does not seem to be mandated to check that the random
identity needs to be unique within a cell. Also, from experience we see
that this only happens when the same UE "comes back"; so since one UE
can only have one connection, the other RRC UE contexts (with the same
identity) should be removed at some point, anyway, leaving only one with
the same identity.
nr_fill_indication() fills CRC and RX requests, to be sent from L1 to
L2. Before this commit, nr_fill_indication() is called when
- we finally decoded LDPC (or not)
- low signal on PUSCH
This might happen at the same time, i.e., nr_fill_indication() might try
to fill both CRC and RX, in the same list, from different threads. This
can lead to this assertion:
Assertion (crc->rnti == rx->rnti) failed!
In handle_nr_ulsch() ../../../openair2/NR_PHY_INTERFACE/NR_IF_Module.c:190
mis-match between CRC RNTI e071 and RX RNTI 5e3b
e.g., e071 is low energy, and while 5e3b related message are filled in
one thread, e071 is being put into the message structure as well.
At least that is my understanding. I could not actually reproduce this
assertion; to be seen if it still happens.
They use 4G NUMBER_OF_UE_MAX, which is not supposed to be present in 5G.
Further, the mutex and variable are global state; for Paging, we should
use F1.
We can only support up to 30 UEs for SRS. In this commit, we change:
- if the total number of UEs is > 32, throw error during compilation to
raise awareness (32 so that a multiple of two still works, everything
else is confusing, see also next point)
- during runtime, handle gracefully if UID is 30 or 31 to not abort (we
can simply not allocate SRS resources)
Also, refactor config_srs() to always give back new memory; the code is
shorter and clearer. Rename to get_contig_srs() to make it explicit.
Robert Schmidt