RSSI threshold for PUSCH & PUCCH power control
To prevent ADC railing or "clipping" when the received power is too
large, introduce RSSI threshold parameters for PUSCH and PUCCH, which
are now configured in units of 0.1 dB. Here is how you can configure and
use these thresholds:
1. Configuration:
- Set the pusch_RSSI_Threshold and pucch_RSSI_Threshold parameters in
your configuration file (e.g., gnb.conf) (MACRLC section).
- These parameters define the maximum acceptable RSSI values for
PUSCH and PUCCH, respectively. The unit is either dBm or dBFS,
depending on the RSSI reporting configuration.
2. Usage:
- The nr_limit_tpc function will automatically adjust the Transmit
Power Control (TPC) commands based on the configured RSSI
thresholds.
- If the RSSI exceeds the threshold, the TPC command will be limited
to prevent further increase in power, thereby avoiding ADC
clipping.
fhi_72: allow to provide dpdk_iova_mode to xran
- Introduce a gNB configuration option that enables users to select the
desired IOVA mode for DPDK ("PA" or "VA") with dpdk_iova_mode
parameters in fhi_72 configuration section. If not set, the default
remains PA mode to ensure backward compatibility with existing
configurations. Detailed information about IOVA modes, including their
advantages and disadvantages, can be found in the DPDK documentation:
Memory in DPDK Part 2: Deep Dive into IOVA
- Using IOVA VA mode allows DPDK to run without requiring SYS_ADMIN
capability for the docker container.
- Switch to IOVA VA mode in the FHI7.2 pipeline and reduce the required
capabilities for the docker container.
Config files improvements for PRACH
Some PRACH parameters in configuration files are not properly set.
- number of SSB per RACH occasion should be 1 when we have only 1 SSB
(it would still work with 1/2 but it makes little sense and might
limit UE selection of ROs).
- some PRACH configuration indices would generate PRACH conflicting with
PUCCH and therefore reducing scheduling capabilities
Further cleanup of some config files still using deprecated fields
In DPDK, IO Virtual Addresses (IOVA) refers to the memory addressing
scheme used for IO operations. The two IOVA modes supported by DPDK are:
- IOVA as Physical Address (PA): IO memory addresses correspond directly
to physical addresses, no address translation required.
- IOVA as Virtual Address (VA): IO memory addresses align with user-space
virtual addresses, requiring IOMMU to remap physical memory.
Previously, this was hardcoded to 0, to use IOVA as PA mode, with xRAN's
DPDK EAL initialization using the "--iova-mode=pa" flag.
This commit introduces a gNB configuration option to allow users to select
the desired IOVA mode. The default remains PA mode to
ensure backward compatibility.
Using IOVA VA mode allows DPDK to run without requiring SYS_ADMIN
capability in the docker container.
NR gNB improvements for analog beam management
- Improvements at gNB MAC layer to properly handle analog beam
management for all channels
- Simple beam switching mechanism based on UE RSRP report
- Introduced new configuration parameters `pusch_RSSI_Threshold` and `pucch_RSSI_Threshold`
(MACRLC section)
- Added `nr_limit_tpc` function in `gNB_scheduler_primitives.c` to limit TPC based on RSSI
threshold.
- Integrated `nr_limit_tpc` in PUCCH and PUSCH power control
Example Configuration
puxch_RSSI_Threshold takes value between -1280 and 0 and is mapped to range -128.0 dBm/dBFS
to 0.0 dBm/dBFS in 0.1 dB increments. Unit depends on RSSI reporting config.
pucch_RSSI_Threshold = -500; # Set the PUSCH RSSI threshold to -50.0dBm/-50dBFS
pucch_RSSI_Threshold = -600; # Set the PUCCH RSSI threshold to -60.0dBm/-60dBFS
New LDPC coding library interface for decoding and encoding complete slots in one call to the library
Previous attempts to integrate LDPC decoding relying on offloading show
the limitation of the original code segment coding interface for the
library implementing LDPC coding. In order to perform the offload and
therefore the decoding in an optimal fashion, it is relevant to provide
the implementation with the broader amount of data possible per call,
which is a slot. A previous MR related to T2 offload managed to offer
an interface for decoding transport blocks by modifying only
nr_ulsch_decoding.c. But this may not be sufficient for performing an
efficient decoding in any situation. Slots could be shared between
multiple transport blocks in case multiple UEs are connected to the RAN,
which makes the transport block size shrink and therefore degrades the
efficiency of the offloading.
This MR offers a broader interface with a gNB decoding entry point in
phy_procedures_nr_gNB.c. The file nr_ulsch_decoding.c now lets the
decoding library implement deinterleaving, rate-unmatching and decoding
for the slot. In gNB encoding and UE decoding and encoding as well,
tasks are partitioned in a similar fashion.
As it allows to feed the implementation with the broadest amount of data
possible, it allows to fit any coding solution in a library. This will
avoid further modification to OAI source code and addition of options to
select an implementation when integrating new decoding solutions. An
implementation of this interface will therefore be offered for every
existing decoding solution in OAI and solutions added in the future will
be provided as independent module code without any modification to the
core of OAI code. The way to choose the decoding solution and to
configure it was also unified using configmodule. The library can be
chosen through the option --loader.ldpc.shlibversion. The slot coding
solutions shipped with this MR can be configured through configmodule
(e.g., T2 address and isolated cores).
This MR includes three coding implementations:
- A wrapper around segment decoding libraries for test purpose: libldpc.so
- A one shot slot coding and encoding with the T2 board: libldpc_t2.so
- A decoder on FPGA using the XDMA driver: libldpc_xdma.so
Improvements brought by this MR:
- Easy integration of a wider variety of LDPC coding solution at gNB and UE
- Easy selection of the LDPC coding solution (option --ldpc-offload-enable is kept for now but it can be ultimately removed)
- T2:
* More efficient when many UEs are connected
* Decoding and encoding in nr-uesoftmodem
GTP: use direct call instead of ITTI
Using ITTI calls for user plane implies (1) a memory allocation, (2)
mutexes, and (3) queueing messages for each user plane packet, which is
heavy. Use a direct API call instead to reduce overhead.
Fronthaul xran library update to F release (2. and final step towards M-plane integration)
- xran library support -> both E and F releases
- RU delay profile removed -> not used in neither of the releases
- DU delay profile updated
- one-way delay measurements support is improved/fixed in the F release.
However, not implemented here as it depends on the RU capabilities
Documentation: add multi-UE deployment with RFsimulator
Extended doc/NR_SA_Tutorial_OAI_nrUE.md with section about how to run multiple UEs
- multiple UEs with namespaces (provided new script)
- multiple UEs with Docker UEs
- updated rfsimulator and channel simulation tutorials
- updated README.md
chore(ci): adding Flexric-RAN integration test
- Triggering a standalone FLEXRIC + 5G-RAN pipeline: OAI-FLEXRIC-RAN-Integration-Test
- will be triggered by the RAN-Container-Parent
- but also by the OAI-FLEXRIC pipeline (to be done once integrated)
- Added an new python option: --FlexRicTag= than if not used, won't have any effect
- Nice addition:
- if --FlexRicTag=develop or --ranCommitID=develop --> will use the latest commit
on either dev or develop branch.
- Scenario-wise
- Using the cn5g deployment file from Luis in documentation, at least we will use
it to make sure it is working at all time
- We can add more test and especially checkers on the flexric calls
Linked to !3085 (merged)
Fronthaul 7.2 improvements (1. step towards M-plane integration)
- added explanations for each parameter used for XRAN library
- added new config files for VVDN, Benetel 550 and Metanoia RUs
- changed config file for Benetel 650
- deleted 8x8 650-550, and added 8x8 650-650 config file
- updated FHI README
- setting one or more VFs; compatibility with Mellanox NIC as well
- fhi_72 section
Since tag 2024.w45/commit f54ca5714e,
standalone mode/--sa is the default and does not exist. Correspondingly,
it has been removed from the documentation.
For users reading recent documentation, but running an older version of
OAI, there might be a mismatch in that --sa is necessary to run OAI, but
not given in the documentation. Provide explanatory text to make users
aware of this.
Set SA mode as default
- Set standalone (SA) mode as the default.
- Adjust commands in Docker Compose files by removing --sa flags and
adding --nsa flags where applicable.
- Add a function to verify that only one mode is being used at a time.
- Update all relevant documentation.