MR !1079 / MR !1108:
1. Read slots from config file and schedules all slots *except* for slots 0 and 10. This is not a problem, since currently we cannot allocate more than six HARQ feedbacks in a slot, but we might have up to 7 with current configuration
2. phytest mode is configurable. From `nr-softmodem -h`:
-m: Set the downlink MCS for PHYTEST mode
-t: Set the uplink MCS for PHYTEST mode
-M: Set the downlink banwdwidth (in PRBs) for PHYTEST mode
-T: Set the uplink banwdwidth (in PRBs) for PHYTEST mode
-D: Bitmap for DLSCH slots (slot 0 starts at LSB)
-U: Bitmap for ULSCH slots (slot 0 starts at LSB)
3. Scheduler prints more information: UE PHR, PUCCH SNR, PUSCH SNR, RSSI
4. The scheduler learned to scheduler DLSCH/ULSCH in mixed slots (if the time domain allocation matches the mixed slot)
5. The scheduler expects
* PDSCH Time Domain allocation index 0 to be the DL slot allocation
* PDSCH TDA index 1 for Mixed DL slot
* PUSCH TDA index 0 for UL slot
* PUSCH TDA index 1 for Mixed UL slot
* PUSCH TDA index 2 for Msg.3
6. Some more cleanup, e.g., separate PDSCH/PUSCH data structures into "semi-static" data (e.g., TDA allocation to use, since it changes seldomly) and "dynamic" data (e.g., RB allocation per slot, which changes every slot)
MR !1137 : Benetel config files fix
The TA calculation takes the CIR peak position error and scales it according to 38.213 section 4.2.
Till now it was simply an integer division "timing_advance_update = sync_pos / bw_scaling".
E.g. in case of bandwidth_scaling == 16, the timing_advance_update was 0 for sync_pos between -15 and +15.
With this change, this range (and thus the UL timing error) will be reduced to -8 and +8.
The rotation compensating the shifted OFDM position _before_ the channel estimation makes the CIR peak move back to 0.
We have to take this into account on gNB side when calculating the timing advance command, and on UE side in the time adjustment.
Currently we cute the PUSCH and PDSCH OFDM symbols starting within the last 1/8th of the CP to avoid ISI.
This time shift leads to a rotation in frequency domain.
The current PRB based channel estimation does not compensate for the rotation _within_ a PRB, leading to bad performance.
This commit should _not_ make it into develop branch, it is just for testing!
Instead, we should do some compensating rotation before channel estimation.
Sakthivel Velumani