Before this commit, the DLSCH scheduler would construct the MAC PDU by
reading RLC data into a memory on the stack, and then construct the PDU
with CEs first. There are at least two problems:
- we need to keep track of the exact number of bytes of CEs (cumbersome)
  to calculate the number of MAC SDUs to include
- we needlessly copy data around.

This commit does the following instead:
- write all CEs first (no need of keeping track of this in DLSCH and a
  separate function)
- then read MAC SDUs directly into nFAPI as much as possible or
  necessary, without recopying

According to SCF222, a single PDCCH allocation groups DCIs that are
within the same BWP and CORESET. Therefore, if we want to allocate
multiple DCIs, we need to decouple PDCCH allocation and DCI (previously
jointly done in nr_configure_pdcch()), especially to be forward
compatible.

***Note that as of this commit, we would still allocate different PDCCH
PDUs for multiple UEs (which we do not support yet, anyway)***

nr_configure_pdcch(): simply take out DCI allocation.

nr_generate_Msg2(): separately allocate dci_pdu in common RA SS, and
rename DCI payload variable. Also, reorganize the function so that it is
first checked for CCE allocation and messages nFAPI messages are
allocated afterwards.

nr_schedule_ue_spec(): separately allocate dci_pdu in UE-specific SS.
Rename DCI payload variable.

nr_schedule_ulsch(): separately allocate dci_pdu in UE-specific SS.
Rename DCI payload variable.

nr_fill_nfapi_dl_sib1_pdu(): separately allocate dci_pdu in common SS.

Initially, filling the PDCCH and PDSCH nFAPI messages was split into a
separate function (in an attempt to keep the code structure similar to
LTE). However, this proved as not helpful: the nr_fill_nfapi_dl_pdu()
just filled the messages, with a parameter list almost size as long as
the actual messages (because most parameters are kind of independent).
This made no sense, so we put it back.

Also, from an understanding POV, they just fill a message as specified
in SCF222, so it should not be a problem.

- No dynamic allocation of PUCCH structures
- Use first PUCCH for HARQ (can only allocate for up to two slots in
  single PUCCH, simplistic nr_acknack_scheduling!)
- Use second PUCCH for CSI, do not multiplex!

Use a "future" UL_tti_req structure to save in between scheduling and
reception slots. Should also work for FDD.

Improvements to decode SIB1 in 3rd party implementations and OAI UE with the same gNB configurations

Francesco Mani authored Oct 23, 2020 and Robert Schmidt committed Nov 03, 2020

The SSB nFAPI message is only sent every 8 frames, and automatically
repeated by the PHY layer in between. This commit sets the vrb_map
structure in those frames in between nFAPI so that the scheduler does
not schedule on such resources.

The phytest preprocessor schedules only one UE, as many RBs as possible
(largest continuous RB region), with a fixed MCS and time domain
allocation.

- adapted the get_band function: the algorithm is now taking into account
  also the UL frequency in order to fetch the proper band (this was failing
  before as some NR bands have the same DL band, e.g. band 65 and 66)
- added new bands to the NR table as per TS 38.101 V16.4.0 (2020)
- made the from_nrarfcn function compatible with UL FDD (this function,
  used for both DL and UL  was previously working with TDD only as it
  did not compute properly the frequency for the UL FDD, throwing asserts)
- introduced common functions to get the NR table idx and the duplex mode,
  removing repeated code in the process
- removed the unused function to get the uldl offset
- improved some logging
- other minor fixes to the relevant code

Get type0_PDCCH_CSS_config parameters at the gNB. SIB1 initialization has been added at SI initialization. SIB1 was transmitted with static parameters.