esp. for LEO NTN scenarios the timing drifts during initial sync, which is mostly compensated with --ntn-initial-time-drift.
But there might be a residual time offset, and by extending the peak search window we make this more tolerant.
Depending on the main source of frequency offset, pre-compensate the UL frequency offset (FO) accordingly.
Therefore modify the flag `--cont-fo-comp` to accept an integer value, where
- `1` specifies, that the main FO contribution comes from the accuracy of the local oscillator (LO)
- `2` specifies, that the main FO contribution comes from Doppler shift
Currently we still activated the DL HARQ process for PUCCH transmission,
and only at the time of the scheduled PUCCH transmission, we actually skip sending the ACK.
This is not only unnecessary, it is at least misleading and strange that
DL HARQ processes can be reused in the meantime, even though they are active...
Therefore simply don't activate the DL HARQ process by skipping the call to set_harq_status() if feedback for it is disabled.
The "writeTimestamp inconsistencies" are coming from the fact that during the actual processing we write `N_TA_offset` samples _and_ `NR_UE_CAPABILITY_SLOT_RX_TO_TX` slots ahead,
but both was not corrently considered in readFrame() and syncInFrame().
Therefore, there was always a warning about a gap in write timestamps as soon the actual processing starts.
The value of ntn_init_time_drift is used at initial sync to compensate for the time drift during initial sync detection.
To perform the initial time and frequency sync, the OAI UE currently takes a snapshot of two frames and then performes PSS correlation, SSS detection and MIB decoding.
Doing this takes much time, several tens of ms. During that time, the DL timing drifts so much, that we immediatedly lose sync again.
Therefore the current OAI UE implementation needs to know the drift rate to compensate for this drift, as we are "blind" while performing the initial sync.
To my undestanding, commercial UEs simply have a faster initial sync, so the DL timing will not drift away too much while performing that initial sync.
The test was actually never executed correctly (unsigned -10 is never <= 10), and log2_approx64_ref() was not accurate enough.
Therefore replace it by directly comparing one value above and one value below each rounding boundary.
To skip the test, we use the gtest command line parameter "--gtest_filter" to filter out the unwanted test.
This parameter is described as follows:
--gtest_filter=POSITIVE_PATTERNS[-NEGATIVE_PATTERNS]
Run only the tests whose name matches one of the positive patterns but
none of the negative patterns. '?' matches any single character; '*'
matches any substring; ':' separates two patterns.
Experiments did show that the time sync is less stable in terrestrial mode if the integral part of the PI controller is used.
So set it to 0.0 by default. For NTN LEO use case we can still use it by providing the command line parameter --time-sync-I 0.2 .
fixes#846
As we don't have SIB19 with continuously updated ta-Common and ta-CommonDrift values yet, the UE can only adapt it's UL timing according to it's DL drift.
This is required for the UE to keep UL sync with fast time drift and relatively long RTT (e.g. LEO satellite).
We should replace this with the standard compliant way as soon as we have SIB19 with continuously updated contents.
While we don't have SIB19 support yet, UE gets this parameter from command line, just like --ntn-koffset and --ntn-ta-common.
We use this value to initialize the UE's time-tracking PI controller accumulator.
This allows to correctly track the time even if the delay is changing significantly (e.g. due to LEO satellite movement).
We also use it to compensate for the time drift that happenes while performing the initial sync.
This now allows to indicate "there was a new sampleShift calculation, and the actual value is 0"
additionally to "there was no new sampleShift calculation".
sched_ul_bytes is reduced already in case the last HARQ round fails through handle_nr_ul_harq() -> abort_nr_ul_harq().
Therefore, the reduction in nr_rx_sdu() is wrong, and btw. it wrongly assumes the max. UL HARQ rounds to 4.
So simply remove this peace of code in nr_rx_sdu().
sched_ul_bytes tracks the volume of in-flight data.
When data is successfully received, sched_ul_bytes is decreased in nr_rx_sdu().
In case of reusing HARQ processes, the tb_size stored there is not correct.
Therefore use the actual SDU size instead.
The actual propagation delay should not be smaller than the one specified.
A too short propagation delay might result in too early reception of Msg1, and with that in a mis-detection of the RAPID.
Until commit d74b2bd19f, the PSS detection step size was 4, anyways.
The PSS detection step size is a compromise between detection duration and accuracy.
The most accurate detection step size would be 1, but this would lead to even longer initial sync time.
According to the RRC specification, cellSpecificKoffset is:
Scheduling offset used for the timing relationships that are modified for NTN (see TS 38.213 [13]).
The unit of the field K_offset is number of slots for a given subcarrier spacing of 15 kHz.
If the field is absent UE assumes value 0
This parameter `cellSpecificKoffset_r17` can be set via UE command line parameter `--ntn-koffset`.
The RTT for GEO satellites is more than 500 ms.
And as the TA update interval must be greater than the RTT, we increase it to 1 second instead of 100 ms.
Should also do no harm for terrestrial networks.
According to the RRC specification, cellSpecificKoffset is:
Scheduling offset used for the timing relationships that are modified for NTN (see TS 38.213 [13]).
The unit of the field K_offset is number of slots for a given subcarrier spacing of 15 kHz.
If the field is absent UE assumes value 0
This parameter `cellSpecificKoffset_r17` can be set in the gNB conf file, in the section `servingCellConfigCommon`
make sure the SSB is offset by 4 PRBs from the BW start.
Therefore, the ARFCN for the SSB center must be offset by 14 PRB from the ARFCN for the BW start.
Thomas Schlichter