set_latency_target() attempts to set keep "low latency" by
- writing a specific latency to /dev/cpu_dma_latency
- setting manually the minimum CPU processor frequency to be the maximum
There is no functionality to undo this after stopping the softmodem(s),
and most users are probably not even aware that OAI does this. It is
generally preferable to set this beforehand using a governor or by
disabling sleep states (as outlined in the tutorial, and in a follow-up
commit in the performance tuning docs).
The previous mlockall() call, to lock memory to RAM, is retained in a
new function. There were additional mlockall() calls, which have been
replaced with lock_memory_to_ram(), where necessary.
A particular GCC version (v13?) used by CI machines potentially has a
bug that issues a mismatch bound warning on function array arguments.
This commit should prevent it from happening.
There is already a command line option called 'ue-scan-carrier' which
seemed to blindly look for SSB by changing the center frequency by
+/-100Hz if the previous attempt failed. This is probably copied from
LTE and is not suitable for NR. This commit uses this option to either
1. Perform initial sync on one GSCN if the SSB position if known
2. Or scan the all GSCN (if the SSB postion is unknown)
Also, the following is done for re-synchronization
1. Scan all GSCN when UE comes back from IDLE state
2. Scan one GSCN when UE does re-estabishment
Removed dependency of lte-softmodem.h in nr-softmodem.c.
CONFIG_HLP_UESCAN is declared also in lte-softmodem.h.
Changed Info to Debug because the logs are too much if large number of
GSCN scans run concurrently. Print PSS correlation peak and average
power of detected cells.
Till this commit, the UE gets the position of SSB in frequency from
command line and does the syncronization by locating the SSB in time. It
does this by generating a PSS time signal during initialization with the
SSB offset given via command line. Then PSS detection is done by
correlation.
In this commit, the UE computes a list of GSCN in the current NR band
that falls within the current bandwidth for the set center frequency.
For each GSCN in the list, the UE starts a thread and performs the
following:
1. Generate PSS time signal with SSB offset for current GSCN.
2. Detect PSS, SSS and decode PBCH (this step remains the same).
After all threads finishes, the results are collected.
For now, only the first detected PBCH is used to proceed further. So
this PBCH is indicated to MAC and UE exits initial sync.
Future work: The cell search can be standalone feature where the UE
could scan for SSB in the entire NR band. This would require changing
radio's frequency on the fly as the UE's bandwidth would not cover an
entire NR band. The cell detection can futher be imporved by looking
for SIB1 for each decoded PBCH.
* nb_re_pdsch is directly linked to nb_rb_pdsch, if the latter is 0 the
former is also 0
* compute average channel level only when number of RE for PDSCH is not 0
the average channel level will be set to 0 otherwise
* Added a log message to handle this special case, which is consequence
of other issues in the RX chain
* with this commit, the inconsistency in the RX chain will be handled
in later in nr_ue_pdsch_procedures with a demodulation failure
other minor changes:
* Improved clarity by using NR_NB_SC_PER_RB instead of hard-coded value 12 in nb of RBs calculation
* cleaned up unused variable and outdated comments
This reverts commit 0d0e111135. It was
set to UE RX to TX time to 2 as it was deemed that the UE could sustain
this time. However, we noticed a degradation of performance, so reset
the RX to TX time to something higher to ensure proper performance.
Correctly compute the offset of data to unscramble in PUSCH processing
at the gNB. Rename variables to make them easier to spot (instead of
"s"), and remove a global variable.
Closes: #734
We access G_N at indexes that are not necessarily 32-byte aligned,
leading to segfaults. Use simde_mm256_loadu_si256() to load from memory
at an unaligned memory address to avoid the segfault.
Discovered using clang; it is unclear why gcc did not encounter the same
segfault.
francescomani